The Adaptor Pattern
The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps object with the purpose to make their interfaces look like something they’re not, to adapt a design expecting one interface to a class that implements a different interface. To do this, create an Object A and an Object B. Next, wrap the Object B in an ObjectbAdaptor which converts it and makes it look like Object A . This acts to decouple the client from the implemented interface, especially if we expect the interface to change over time, the adapter encapsulates that change so that the client doesn’t have to be modified each time it needs to operate against a different interface.
The Factory Pattern
The Factory Pattern handles object creation and encapsulates it in a subclass. This decouples the client code in the superclass from the object creation code in the subclass. The factory pattern is good for not having to keep using the new operator as instantiation can cause coupling problems when done in public. That kind of code will often end up in several parts of the application which makes maintenance and updates more difficult and error prone.
Identify the aspects that vary
Add object types
Encapsulate object creation
The Abstract Factory Pattern
Pizza Factory example: To localize all PizzaStore activities to a single PizzaStore class, and still give franchises freedom to have their own regional style just add createPizza() method back into the PizzaStore subclass for each regionalstyle
Interface
Programming to an interface really means programming to a supertype. The point of using an interface is to exploit polymorphism by programming to a supertype so that the actual runtime object isn’t locked into the code. The object assigned to those variables can be of any concrete implementation of the supertype which means the class declaring them doesn’t have to know about the actual object types. Interfaces can not be instantiated. Identify the common behavior, take the parts that vary and encapsulate them, so that later you can alter or extend the parts without affecting the ones that don’t. Implement the behaviors and create instance for them.
Observer Pattern
The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notifies and updated automatically. The subject and observers define the one-to-many relationship. The observers are dependent on the subject such that when the subject’s state changes, the observers get notified. Depending on the style of notification, the observers get notified. Depending on the style of notification, the observer may also be updated with new values. Provides an object design where subjects and observers are loosely coupled. The only thing the subject knows abut an observer is that it implements a certain interface, we can add new observers at any time, we never need to modify the subject to add new types of observers, we can reuse subjects or observes independently of each other, and changes to either the subject or an observer will not affect the other.
Singleton Pattern
The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it. Take a class and let it manage a single instance of itself and prevent any other class from creating a one instance on its own.