Pages

Thursday 18 December 2014

Design Pattern CheatSheet

Observer Pattern : The observer pattern defines a one to many relationship between objects so that when one object changes state all the other dependent objects are notified.

Factory Pattern : encapsulates object creatio. Defines an interface for creating an object, but lets subclass decide which class to instantiate. Factory method lets a class defer instantiation to subclasses. 

Adapter Pattern : Converts interfaces of a class to another interface that clients expect. Lets classes work together that wouldnt otherwise because of incompatible interfaces.

Singleton - Use double check locking because the synchronization is only needed for the object instantiation part. If you already have an instance of that object, you dont need to do the synchronization. Declare the instance as static volatile, the constructor as private and a getInstance function as public static. 

Command Pattern : encapsulates a request as an object , thereby letting you parameterize other objects with different requests, queue or log requests and support undoable operations. Light will have OnCommand and OffCommand and it will be there in the remote control. You can queue such incoming commands.Command pattern gives you a way to package a piece of computation or actions and the receiver and store it as a first class object.

Decorator Pattern : Doesnt alter the interface, but add responsibility to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. In the decorator design pattern the class or abstract class that is being extended is also present as a property in the class extending it.

Facade : Make interface simpler. The facade pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.

Strategy Pattern : Encapsulate interchangeable behavior and use delegation to decide which behavior to use. 

Template Method : Defines the skeleton of an algorithm in a method in an abstract class, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

A hook is a method that is defined in an abstract class, but only given an empty or default implementation. This gives the subclass the ability to hook into the algorithm at various points, if they wish, a subclass is also free to ignore the hook.

Iterator Pattern : The iterator pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation

Observer Pattern - The observer interface is implemented by all observers. The update method has paramters which are received by all observers when the state of the subject changes.
WeatherData implements the Subject interface which registersObservers, UpdatesObservers, RemovesObservers. It also holds a list of observers.
The ConcreteObserver stores a reference to the subject where it registers. This is not necessarily needed. This functionality is given so that the observer can unregister from the subject if it feels like.

We say that a module has high cohesion when it is designed around a set of related functions and say it has low cohesion when it is designed around a set of unrelated functions. Classes that adhere to a single responsibility principle have high cohesion. Every responsibility of a class is an area of change. More than one responsibility means more than one area of change. 

OO Principles :
  1. Encapsulate what varies (encapsulating object creation is factory, encapsulating method invocation is , encapsulating algorithms is template pattern, encapsulate iteration over different data types is iteration, )
  2. Favor composition over inheritance
  3. Program to interfaces not implementations
  4. Strive for loosely coupled designed between objects that interact
  5. Classes should be open for extension but closed for modification
  6. Depend on abstractions and do not depend on concretions
  7. Only talk to friends (Facade pattern and principle of least knowledge)
  8. Dont call us, we will call you (Hollywood principle, Template)

Principles :
  1. Dependency Inversion : Avoid the use of concrete classes and instead work with as much abstractions as possible.
  2. Principle of least knowledge : Objects should talk to only few friends. The principle prevents our system such that we have large number of classes coupled together so that changes to one part of the system cascade to other parts. When you build a lot of dependencies between many classes you build a fragile system that will be costly to maintain and difficult for others to understand. 
  3. Hollywood Principle : Dependency rots happen when you have high level components depending on low level components depending on high level components depending on sideways components depending on low level components and so on. We allow low level components to hook themselves into a system, but the high level components determine when they are needed and how. In other words, the high level components give the low level components a "Dont call us, we will call you.".
  4. Open Principle : Classes should be open for extension but closed for modification - decorator pattern

No comments:

Post a Comment