When there are some sub tasks or series of subsystems.
In such cases we need to bother about all the subsystems or we can say we need to remember all the classes, methods and sequence of calling. So to avoid this situation, we can use Facade pattern which provides an interface to client code and hide all the subsystems.
Lets takes an example for facade design pattern. Suppose I need to turn off my Desktop. So the activities involve in this task is : 1. Save my Work and ShutDown Windows. 2. Turn off Monitor 3. Turn off UPS. So there are 3 subsystems and my program looks like: There are 3 different classes with their respective methods. Continue reading →
Abstract factory pattern in useful when the client needs to create objects which are somehow related. If we need to create the family of related or dependent objects, then we can use Abstract Factory Pattern. Continue reading →
Repository and Unit of work pattern provides a clean way to access data using ORMs, keep all the data access logic in one central location and at the same time maintain the test-ablility of the application. Continue reading →
The observer design pattern is yet another, one of my favorite design patterns which falls in the category of “behavioral pattern“. Going by its name, we can say that observer is something (objects in case of OOPS) which islooking upon (observing) other object(s). Observer pattern is popularly known to be based on “The Hollywood Principle” which says- “Don’t call us, we will call you.” Pub-Sub (Publisher-Subscriber) is yet another popular nickname given to Observer pattern. Continue reading →
The Facade pattern is a common software design pattern used to create a simple unified interface for a set of interfaces in a system. The Facade interface is a higher-level interface that allows easier control of a set of subsystem interfaces without affecting the subsystem interfaces.The Facade pattern encourages composition over inheritance, and is a good way to clean up and simply a set of complex subsystems into one more simple, higher-level interface. Continue reading →