This chapter is a subset of the “Q&A Session” sections of all the chapters in this book. Many of these questions were not discussed in specific chapters because the related patterns were not covered yet. I highly recommend that in addition to the following Q&As, you go through all the “Q&A Session” sections in the book to better understand the patterns.
30.1 Which design pattern do you like the most?
It depends on many factors, such as the context, situation, demand, constraints, and so on. If you know about all the patterns, you will have more options to choose from.
30.2 Why should developers use design patterns?
A common answer is that they are reusable solutions for software design problems that repeatedly appear in real-world software development. But I mentioned it before (for example, in the Q&A session of Chapter 28), you need to analyze various aspects, such as the context and intent of the problem before you implement a pattern.
30.3 What is the difference between the Command and Memento patterns?
All actions are stored for the Command pattern, but the Memento pattern saves the state only on request. Additionally, the Command pattern can support undo operations for every action, but the Memento pattern does not need that. I strongly recommend you to visit the Q&A 19.4 from Chapter 19 to understand the difference clearly.
30.4 What is the difference between the Facade pattern and the Builder pattern?
The Facade pattern aims to make a specific portion of code easier to use. It abstracts details away from the developer.
The Builder pattern separates the construction of an object from its representation. In Chapter 3, the director is calling the same method, Construct() in demonstration 1 and ConstructCar() in demonstration 2, to create different types of vehicles. In other words, you can use the same construction process to create multiple types.
30.5 What is the difference between the Builder pattern and Strategy pattern? They have similar UML representations.
First, you must examine the intent. The Builder pattern falls into the category of creational patterns, and the Strategy pattern falls into the category of behavioral patterns. Their areas of focus are different. When you consider the Builder pattern, you can use the same construction process to create different types, when you use the Strategy pattern, you have the freedom to select an algorithm at runtime.
30.6 What is the difference between the Command pattern and the Interpreter pattern ?
In the Command pattern, commands are objects. In the Interpreter pattern, the commands are sentences. In the Interpreter pattern, you can make your own rule for evaluation and build the syntax tree. For a simple grammar, it is fine, but it becomes tough to implement when your grammar is complex. It is because the cost of building an interpreter can be a big concern for you.
30.7 What is the difference between the Chain of Responsibility pattern and Observer pattern?
For the Observer pattern, all registered users are notified or get requests (for the change in the subject) in parallel. For the Chain of Responsibility pattern, you may not reach the end of the chain, so all users do not need to handle the same scenario. The request can be processed much earlier by some user who is placed at the beginning of the chain. I suggest that you refer to Q&A 14.4.
30.8 What is the difference between the Chain of Responsibility pattern and Decorator pattern?
They are not the same at all, but you may think that they are similar in their structures. Like FAQ 30.7, in the Chain of Responsibility pattern, in general, only one class handles a request, but in the Decorator pattern, all classes handle a request. You must remember that decorators are effective in the context of adding and removing responsibilities only. If you can combine the Decorator pattern with the single responsibility principle, you can add (or remove) a single responsibility at runtime.
30.9 What is the difference between the Mediator pattern and the Observer pattern ?
The GoF says, “These are competing patterns. The difference between them is that Observer distributes communication by introducing observer and subject objects, whereas a mediator object encapsulates the communication between other objects.”
Here I suggest you consider the examples of the Mediator pattern in Chapter 21. In demonstration 2, I explained that a sender could receive a message to the target receiver if he is online. I described how to restrict an outsider and promote security. But in the observer pattern, a subject/broadcaster normally does not care about its observer’s state. It simply broadcast the messages.
The GoF book is telling that you may face fewer challenges when making reusable observers and subjects than when making reusable mediators, but regarding the flow of communication, Mediator scores higher than Observer.
30.10 Which one do you prefer, a singleton class or a static class ?
It depends. First, you can create objects of a singleton class, which is not possible with a static class. So, the concepts of inheritance and polymorphism can be implemented with a singleton class. Also, some developers believe that mocking a static class (e.g., consider unit testing scenarios) in a real-world application is challenging.
30.11 How do you distinguish between proxies and adapters ?
Proxies work on similar interfaces as their subjects. Adapters work on different interfaces (to the objects they adapt).
30.12 How are proxies different from decorators?
There are different types of proxies, and they vary by implementation. So, some of these implementations may be close to decorators. For example, a protection proxy might be implemented like a decorator. But you must remember that decorators focus on adding responsibilities, while proxies focus on controlling the access to an object.
30.13 How are mediators different from facades?
In general, both simplify a complex system. In a Mediator pattern, a two-way connection exists between a mediator and the internal subsystems. In contrast, in a Facade pattern, you generally provide a one-way connection (the subsystems do not know about facades).
30.14 Is there any relation between the Flyweight pattern and the State pattern?
The GoF book mentions that the Flyweight pattern can help you to decide when and how to share the state objects.
30.15 What are the similarities among the Simple Factory , Factory Method , and Abstract Factory design patterns ?
All of them encapsulate object creation, which suggests that you code to the abstraction (interface) but not to the concrete classes. Simply put, each of these factories promotes loose coupling by reducing the dependencies on concrete classes.
30.16 What are the differences among the Simple Factory, Factory Method, and Abstract Factory design patterns?
This is an important question that you may face in various job interviews. First, refer to Q&A 5.3 in Chapter 5, and if needed, go through all the Q&A sessions in Chapters 4 and 5.
30.17 How do you distinguish the Singleton pattern from the Factory Method pattern ?
The Singleton pattern ensures that you get a unique instance each time. It also restricts the creation of additional instances.
But the Factory Method pattern does not say that you only get a unique instance. Most often, this pattern creates as many instances as you want, and the instances are not necessarily unique. These newly typed instances may implement a common base class. (Just remember that the Factory method lets a class defer instantiation to subclasses, according to the GoF definition.)
30.18 How does the Template Method pattern differ from the Strategy pattern?
In the Strategy pattern, you can vary the entire algorithm using delegation. On the other hand, using the Template Method pattern, you vary only certain steps in an algorithm using inheritance, but the overall flow of the algorithm is unchanged.
30.19 How do you distinguish the Visitor pattern from the Strategy pattern?
In the Strategy pattern, each subclass uses a different algorithm to solve a common problem. But in a Visitor design pattern, each of visitor subclasses may provide different functionalities from each other.
30.20 How null objects are different from proxies?
In general, proxies act on real objects at some point in time, and they may also provide some behavior. But a null object does not do any such operation.
30.21 How do you distinguish the Interpreter pattern from the Visitor pattern?
With the interpreter pattern, you represent simple grammar as an object structure, but in a Visitor pattern, you define some specific operations that you want to use on an object structure. In addition to this, an interpreter has direct access to the properties that are needed, but in a Visitor pattern, you need special functionalities (similar to an observer) to access them.
30.22 How do you distinguish the Flyweight pattern from the Object Pool pattern ?
I did not discuss the Object Pool pattern in this book. But if you know the Object Pool pattern already, you notice that in the Flyweight pattern, flyweights can have intrinsic and extrinsic states. So, if a flyweight has both states, its states are divided, and the client needs to pass part of the state to it. Also, in general, the client does not change the intrinsic state because it is shared.
Object Pool does not store any part of the state outside; all state information is stored/encapsulated inside the pooled object. Also, clients can change the state of a pooled object.
30.23 How are libraries or frameworks similar to and different from design patterns?
They are not design patterns. They provide the implementations which you can use directly in your application. But they can use the concept of the patterns in those implementations.
30.24 What is a callback method ?
It is a method that can be invoked after you perform some specific operations. You’ll often see the usage of this kind of method in asynchronous programming, and it can be useful when you do not know the exact finishing time of prior operations, but you want to start some specific task once the prior task is over. You should refer to demonstration 7 in Chapter 27 to understand it better.