Software design patterns
Thursday 27th of September 2012 02:55:58 PM
- The intent of ADAPTER is to provide the interface that a client expects while using the services of a class with a different interface.
- The intent of the FACADE pattern is to provide an interface that makes a subsystem easy to use.
- The intent of the COMPOSITE pattern is to let clients treat individual objects and compositions of objects uniformly.
- The intent of the BRIDGE pattern is to decouple an abstraction from the implementation of its abstract operations, so that the abstraction and its implementation can vary independently.
- The intent of the SINGLETON pattern is to ensure that a class has only one instance and to provide a global point of access to it.
- The intent of the OBSERVER pattern is to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified so that they can react to the change.
- The intent of the MEDIATOR pattern is to define an object that encapsulates how a set of objects interact; this promotes loose coupling, keeping the objects from referring to one another explicitly, and lets you vary their interaction independently.
- The intent of the PROXY pattern is to control access to an object by providing a surrogate, or placeholder, for it.
- The intent of the CHAIN OF RESPONSIBILITY pattern is to avoid coupling the sender of a request to its receiver, by giving more than one object a chance to handle the request.
- The intent of the FLYWEIGHT pattern is to use sharing to support large numbers of fine-grained objects efficiently.
- The intent of the BUILDER pattern is to move the construction logic for an object outside the class to be instantiated.
- The intent of FACTORY METHOD is to let a class developer define the interface for creating an object while retaining control of which class to instantiate.
- The intent of ABSTRACT FACTORY, or KIT, is to allow the creation of families of related or dependent objects.
- The intent of the PROTOTYPE pattern is to provide new objects by copying an example rather than by bringing forth new, uninitialized instances of a class.
- The intent of the MEMENTO pattern is to provide storage and restoration of an object’s state.
- The intent of TEMPLATE METHOD is to implement an algorithm in a method, deferring the definition of some steps of the algorithm so that other classes can redefine them.
- The intent of the STATE pattern is to distribute state-specific logic across classes that represent an object’s state.
- The intent of STRATEGY is to encapsulate alternative approaches, or strategies, in separate classes that each implement a common operation.
- The intent of the COMMAND pattern is to encapsulate a request in an object.
- The intent of the INTERPRETER pattern is to let you compose executable objects according to a set of composition rules that you define.
- The intent of DECORATOR is to let you compose new variations of an operation at runtime.
- The intent of the ITERATOR pattern is to provide a way to access the elements of a collection sequentially.
- The intent of VISITOR is to let you define a new operation for a hierarchy without changing the hierarchy classes.
- Identify the aspects of your application that vary and separate them from what stays the same. In other words, take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't.
- Program to an interface, not an implementation.
- Favour composition over inheritance.
- Strive for loosely coupled designs between objects that interact.
- Classes should be open for extension, but closed for modification.
- Depend upon abstractions. Do not depend upon concrete classes (Dependency Inversion Principle).