Software Design Patterns

Singleton Pattern

Context

Creating more than one instance of a certain class is undesirable due to some reason * Example 1 * Example 2 . If multiple clients need to interact with an instance of the said class, they should share the same single instance. Such a single instance is commonly known as a singleton.

Solution

Make the constructor of the singleton class private. Provide a public method to access the singleton instance.

As shown, the solution makes the constructor private (note the “-“ visibility marker for the constructor), which prevents instantiation from outside the class. The single instance of the singleton class is maintained by a private class-level variable. Access to this object is provided by a public class-level operation getInstance(). In the skeleton code above, getInstance() instantiates a single copy of the singleton class when it is executed for the first time. Subsequent calls to this operation return the single instance of the class.

public class ClassicSingleton {
   private static ClassicSingleton instance = null;
   private ClassicSingleton() {
      // Exists only to defeat instantiation.
   }
   public static ClassicSingleton getInstance() {
      if(instance == null) {
         instance = new ClassicSingleton();
      }
      return instance;
   }
}

class GlobalClass
{
    int m_value;
    static GlobalClass *s_instance;
    GlobalClass(int v = 0)
    {
        m_value = v;
    }
  public:
    int get_value()
    {
        return m_value;
    }
    void set_value(int v)
    {
        m_value = v;
    }
    static GlobalClass *instance()
    {
        if (!s_instance)
          s_instance = new GlobalClass;
        return s_instance;
    }
};

Which of the following is an ideal situation for using Singleton pattern?

• Utility methods used by many class in the application.
• A database manager shared by different component of the application.
• A constant String defined in every controller.

• Utility methods used by many class in the application.
• Database manager shared by different component of the application.
• A constant String defined in every controller.

Database is a shared resources here, and by using singleton pattern, we have better control over the database operations.

• Do the exercise given in SE-EDU: Addressbook Level 4: Apply Design Patterns

• GoF Book
• Resource 2
• Resrouce 3

Façade Pattern

Context

Components need to access functionality deep inside other components. For example, the UI component of a Library system might want to access functionality of the Book class contained inside the Logic component.

Problem

Access to the component should be allowed without exposing its internal details. For example, the UI component should access the functionality of the Logic component without knowing that it contained a Book class within it.

Solution

Include a Façade class that sits between the component internals and users of the component such that all access to the component happens through the Façade class. The following class diagram shows the application of the Façade pattern to the Library System example. In this example, the LibraryLogic class acts as the Façade class.

Code Example

The following ShapeMaker is a Façade class. The caller class who uses ShapeMaker could use it to draw different shape, but the implementation detail and the actual Shape class is invisible to the caller class.

public class ShapeMaker {
   private Shape circle;
   private Shape rectangle;
   private Shape square;

   public ShapeMaker() {
      circle = new Circle();
      rectangle = new Rectangle();
      square = new Square();
   }

   public void drawCircle(){
      circle.draw();
   }
   public void drawRectangle(){
      rectangle.draw();
   }
   public void drawSquare(){
      square.draw();
   }
}

Command Pattern

Context

A system is required to execute a number of commands, each doing a different task. For example, a system might have to support Sort, List, Reset commands.

Problem

It is preferable that some part of the code execute these commands without having to know each command type. For example, there can be a CommandQueue object that is responsible for queuing commands and executing them without knowledge of what each command does.

Solution

In the example solution below, the CommandCreator creates List, Sort, and Reset Command objects and adds them to the CommandQueue object. The CommandQueue object treats them all as Command objects and performs the execute/undo operation on each of them without knowledge of the specific Command type. When executed, each Command object will access the DataStore object to carry out its task. The Command class can also be an abstract class or an interface.

The general form of the solution is as follows.

The <<Client>> creates a <<ConcreteCommand>> object, and passes it to the <<Invoker>>. The <<Invoker>> object treats all commands as a general <<Command>> type. <<Invoker>> issues a request by calling execute() on the command. If a command is undoable, <<ConcreteCommand>> will store the state for undoing the command prior to invoking execute(). In addition, the <<ConcreteCommand>> object may have to be linked to any <<Receiver>> of the command before it is passed to the <<Invoker>>. Note that an application of the command pattern does not have to follow the structure given above. The essential element is to have a general <<Command>> object that can be passed around, stored, executed, etc.

Code Example

public interface Command {
   void execute();
}

public class ConcreteCommand implements Command {
    public void execute() {
      // Do something
    }
}

public class OtherConcreteCommand implements Command {
    public void execute() {
      // Do other thing
    }
}

public class Invoker {
    List<Command> cmdList = new ArrayList<Command>();

    public void addCmd(Command cmd) {
        cmdList.add(cmd);
    }

    public void executeAll() {
        for (Command cmd : cmdList) {
            cmd.execute();
        }
        cmdList.clear();
    }
}

public static void main(String[] args) {

    Command cmd1 = new ConcreteCommand();
    Command cmd2 = new OtherConcreteCommand();

    Invoker invoker = new Invoker();
    invoker.addCommand(cmd1);
    invoker.addCommand(cmd2);

    invoker.executeAll();
}

Exercise

Model-View-Controller (MVC) Pattern

Context

Most applications support storage/retrieval of information, displaying of information to the user (often via multiple UIs having different formats), and changing stored information based on external inputs.

Problem

To reduce coupling resulting from the interlinked nature of the features described above.

Solution

To decouple data, presentation, and control logic of an application by separating them into three different components: Model, View and Controller.

• View: Displays data, interacts with the user, and pulls data from the model if necessary.
• Controller: Detects UI events such as mouse clicks, button pushes and takes follow up action. Updates/changes the model/view when necessary.
• Model: Stores and maintains data. Updates views if necessary.

The relationship between the components can be observed in the diagram below. Typically, the UI is the combination of view and controller.

Given below is a concrete example of MVC applied to a student management system. In this scenario, the user is retrieving data of one student.

In the diagram above, when the user clicks on a button using the UI, the ‘click’ event is caught and handled by the UiController.

Note that in a simple UI where there’s only one view, Controller and View can be combined as one class.

There are many variations of the MVC model used in different domains. For example, the one used in a desktop GUI could be different from the one used in a Web application.

Observer Pattern

Here is another scenario from the same student management system where the user is adding a new student to the system.

Now, assume the system has two additional views used in parallel by different users:

• (a) StudentListUi : that accesses a list of students and
• (b) StudentStatsUi : that generates statistics of current students.

When a student is added to the database using NewStudentUi shown above, both StudentListUi and StudentStatsUi should get updated automatically, as shown below.

However, the StudentList object has no knowledge about StudentListUi and StudentStatsUi (note the direction of the navigability) and has no way to inform those objects. This is an example of the type of problem addressed by the Observer pattern.

Context

An object (possibly, more than one) is interested to get notified when a change happens to another object. That is, some objects want to ‘observe’ another object.

Problem

A bidirectional link between the two objects is not desirable. However the two entities need to communicate with each other. That is, the ‘observed’ object does not want to be coupled to objects that are ‘observing’ it.

Solution

The Observer pattern shows us how an object can communicate with other objects while avoiding a direct coupling with them.

The solution is to force the communication through an interface known to both parties. A concrete example is given below.

Here is the Observer pattern applied to the student management system.

During initialization of the system,

1.First, create the relevant objects.

StudentList studentList = new StudentList(); 
StudentListUi listUi = new StudentListUi(); 
StudentStatusUi statusUi = new StudentStatsUi();

2.Next, the two UIs indicate to the StudentList that they are interested in being updated whenever StudentList changes. This is also known as ‘subscribing for updates’.

studentList.addUi(listUi);
studentList.addUi(statusUi);

Within the addUi operation of StudentList, all Observer objects subscribers are added to an internal data structure called observerList.

//StudentList class
public void addUi(Observer o) { 
    observerList.add(o);
}

As such, whenever the data in StudentList changes (e.g. when a new student is added to the StudentList), all interested observers are updated by calling the notifyUIs operation.

//StudentList class
public void notifyUIs() {
for(Observer o: observerList) //for each observer in the list
    o.update();
}

UIs can then pull data from the StudentList whenever the update operation is called.

//StudentListUI class
public void update() {
    //refresh UI by pulling data from StudentList
}

Note that StudentList is unaware of the exact nature of the two UIs but still manages to communicate with them via an intermediary.

Here is the generic description of the observer pattern:

• <<Observer>> is an interface: any class that implements it can observe an <<Observable>>. Any number of <<Observer>> objects can observe (i.e. listen to changes of) the <<Observable>> object.
• The <<Observable>> maintains a list of <<Observer>> objects. addObserver(Observer) operation adds a new <<Observer>> to the list of <<Observer>>s.
• Whenever there is a change in the <<Observable>, the notifyObservers() operation is called that will call the update() operation of all <<Observer>>s in the list.

In a GUI application, how is the Controller notified when the “save” button is clicked? UI frameworks such as JavaFX has inbuilt support for the Observer pattern.

Abstraction occurrence pattern

Context

There is a group of similar entities that appears to be ‘occurrences’ (or ‘copies’) of the same thing, sharing lots of common information, but also differing in significant ways.

For example, in a library, there can be multiple copies of same book title. Each copy shares common information such as book title, author, ISBN etc. However, there are also significant differences like purchase date and barcode number (assumed to be unique for each copy of the book). Other examples include episodes of the same TV series and stock items of the same product model (e.g. TV sets of the same model).

Problem

Representing the objects mentioned previously as a single class would be problematic (refer to anti-pattern description below). A better way to represent such instances is required, which should avoid duplicating the common information. Without duplicated information, inconsistency is avoided should these common information be changed.

Anti-patterns

Take for example the problem of representing books in a library. Assume that there could be multiple copies of the same title, bearing the same ISBN number, but different serial numbers. The above diagram shows an inferior or incorrect design for this problem. It requires common information to be duplicated by all instances. This will not only waste storage space, but also creates a consistency problem. Suppose that after creating several copies of the same title, the librarian realized that the author name was wrongly spelt. To correct this mistake, the system needs to go through every copy of the same title to make the correction. Also, if a new copy of the title is added later on, the librarian has to make sure that all information entered is the same as the existing copies to avoid inconsistency.

The design above segregates the common and unique information into a class hierarchy. Each book title is represented by a separate class with common data (i.e. Name, Author, ISBN) hard-coded in the class itself. This solution is worse than the first as each book title is represented as a class, resulting in thousands of classes. Every time the library buys new books, the source code of the system will have to be updated with new classes.

Solution

The solution is to let a book copy be represented by two objects instead of one, as given below.

In this solution, the common and unique information are separated into two classes to avoid duplication. Given below is another example that contrasts the two situations before and after applying the pattern.

The general idea can be found in the following class diagram:

The <<Abstraction>> class should hold all common information, and the unique information should be kept by the <<Occurrence>> class. Note that ‘Abstraction’ and ‘Occurrence’ are not class names, but roles played by each class. Think of this diagram as a meta-model (i.e. a ‘model of a model’) of the BookTitle-BookCopy class diagram given above.

Code Example

class MetaBook {
    String name;
    String author;
    String isbn;
    List<BookCopy> copies;
}

class BookCopy {
    MetaBook meta;
    String serial;
}

class MetaBook {
    public:
        string name;
        string author;
        string isbn;
        vector<BookCopy> copies;
};

class BookCopy {
    public:
        string serial;
        MetaBook meta;
}

Exercise

class TVSeries {
    String seriesName;
    String producer;
    List<Episode> episodes;
}

class Episode {
    TVSeries series;
    int number;
    String title;
    String storySynopsis;
}