While I already covered a small number of design patterns in an earlier article "Article 17 - Technical Interview Questions - Design Patterns", there are many more design patterns worth noting. Although some design patterns may not be as common in interview questions, they are, nonetheless, invaluable to have. Learn them.
The Factory pattern is useful when you have multiple ways to instantiate a particular object and you want to ensure that the instantiation process is consistent.
Consider a function that returns the length of a stick. We can instantiate this stick object using various constructors for different regions (since different regions have different measurement scales: imperial, metric, and others). Instead, we can use the Factory pattern to define functions (as part of the Stick class, which are normally static methods) that convert and return an instance of the class. For example, some methods can be fromCentimeter() or fromFeet() that generates a Stick object of a certain length given either centimeter or feet, respectively.
The Abstract Factory pattern is related to the Factory pattern, except, this pattern uses a common instantiation interface and lets the concrete (often derived class) provide the particular instantiation.
For example, a Document abstract factory class could provide the interface createLetter() or createMemo(), while derived classes will implement those methods to provide specific objects such as a BorderedDocument class.
This pattern is different from the Factory pattern, which generates objects as an instance of itself, whereas the Abstract Factory pattern generates an object of any derived class.
This pattern is used to maintain a consistant number of resources available for the program. Initially, the program will generate x number of resources and sets them aside in a pool. Whenever the program requests a resource, it retrieves it from the pool.
This approach is used whenever generating and destroying a resource is expensive, often the case with database connections (handshaking and authentication procedures may be expensive).
Beware of resource leaks which can occur from many situations. Consider a multithreaded program, where each thread acquires and returns a particular shared resource (i.e. database connection) from the resource manager. If any particular thread acquires a shared resource but dies before returning the shared resource, it becomes a leaked resource (like a leak memory). One method to prevent or recover is to have the resource manager perform more duties (at the expense of more processor utilization) to determine any overloaned resource and reclaim it at a future. For instance, a maximum time limit per loan. However, setting a correct limit is difficult, so this approach may not be the best. In an incorrect situation, the time limit may be too short, and thus prematurely terminating the thread's work. In other (worst cases), all threads acquire all resources and hold them and more threads are waiting the resource. What we have is starvation.
This pattern, although used, is a lack luster method to add functionality in the future, that was not added earlier. It removes the need to rewrite the original code for additional changes. While it works, and avoids breaking the original class's functionality, if the original class changes functionality, this pattern may not behave as intended.
It works by encapsulating a reference to the original object, and overriding any particular method it wants to extend functionality. The overrided method normally calls the original's object's method as well (provided it wants the original functionality).
Unlike the name suggests, this pattern allows dynamic swapping of different algorithms that share the same interface. For example, we are given a list, and we want to sort this list. Using the Strategy pattern, we can sort the list using quicksort, bubblesort, selection sort, and any other sort that implements the same interfaces as these. For example, the Java Collections.sort() function uses this pattern to allow the virtual machine to change the sorting algorithm depending on efficiency (internally).
In this pattern, a common object is shared between multiple objects to reduce memory consumption.
One good example, is Java's Integer class. In this class, there is a static variable called, MAX_VALUE, which is shared between all instances so that any object can declare a maximum integer value using the same value.
This pattern is used as a hook in which derived classes can provide a specific implementation to a particular generalized algorithm. For instance, we may have (in the base class) a function that performs some generalized traversal of a binary tree and which each node traversal, the algorithm will invoke the hook() function. A derived class can override this hook() function to perform the traversal in different ways, such as preorder, inorder, or postorder traversal.
This is an important pattern, it is used to separate logic (algorithm) and the object's definition.
When we have a structured object, say a filesystem object that contains a list of files and folders. We want to support some operations on this filesystem. Initially, we may want to have the functions open(), or read(). Later we may want to add functionality such as search(). We do not want to change the defintion of the File or Folder class.
What we would do is have a Visitor object that understands each object that it can use and visit the lise of files and folders, recursively, and operate on them again. That way, when we add functionalities, we minimize the number of changed class definitions.
For this to work, the visitor object must know each concrete object that it works with. However, each concrete object (being worked on) only needs to know the interface of the visitor.
cZx4BT Major thanks for the article.Much thanks again. Want more.
Thank you ever so for you post.Really thank you! Great.
Thank you for your article.Really looking forward to read more. Want more.
Looking forward to reading more. Great article post.Really looking forward to read more. Keep writing.
Very good blog post.Really looking forward to read more. Great.