{"id":13,"date":"2012-06-26T22:37:04","date_gmt":"2012-06-26T20:37:04","guid":{"rendered":"http:\/\/andras.palfi.hu.rose.arvixe.com\/?p=13"},"modified":"2012-06-26T22:37:04","modified_gmt":"2012-06-26T20:37:04","slug":"design-patterns-and-principles","status":"publish","type":"post","link":"https:\/\/andras.palfi.hu\/?p=13","title":{"rendered":"Design Patterns and Principles"},"content":{"rendered":"

Introduction<\/h2>\n

This article is a cheat sheet of the most used design patterns and principles. This was not made to teach you. This was made to make you remember what you already understood.<\/p>\n

Basic definitions<\/h2>\n

Several design patterns based on the following<\/p>\n

Wrapper<\/h4>\n

Hold a reference to another object. Sometimes it means the owner manages the lifetime of that object sometimes just a simple reference.
\nTo make it flexible this reference is mad through an interface instead of a particular class.<\/p>\n

Delegation<\/h4>\n

Move to certain functionality of another class or use functionality of another class. Applicate it using the wrapper<\/em>.<\/p>\n

Factory<\/h4>\n

Factory is a class or method which has the only task to manage the creation of other classes. Th benefit of it is that different classes don’t have to take care of the classes. Factory usually provides objects through interface.<\/p>\n

Interface<\/h4>\n

The interface is a structure of a class without a specific implementation. It is a contract between two objects. Specifies what methods an object can have – but does not specify the behavior. Different classes implements different behavior to the same interfaces.<\/p>\n

 <\/p>\n

GoF Patterns<\/h2>\n

GoF is the abbreviation of Gang of Four – after the four authors of one of the most fundamental design patterns book<\/p>\n

Creational Patterns<\/strong><\/h3>\n

Abstract Factory<\/strong><\/h4>\n

“Provide an interface for creating families of related or dependent<\/strong> objects without specifying their concrete classes.”
\n<\/em>Client <\/em>uses a factory (referencing Abstract Factory) <\/em>to create instances of different classes. <\/em>Define an interface\/class which declares the methods used by the client and add different implementation of it by overriding the creation methods. This way the client can build products with the same structure using the factory by calling the appropriate method.<\/p>\n

Abstract Factory<\/em> is often implemented using Template Methods<\/em> or Prototype<\/em>.<\/p>\n

Builder<\/strong><\/h4>\n

“Separate the construction of a complex object<\/strong> from its representation so that the same construction process can create different representations”
\nDirector class <\/em>sets up a complex object by calling elementary methods defined in the Builder<\/em> interface\/class. Each builder subclass implements the operations in its own way so Director<\/em> won’t know what parts makes
\nup the object and how are they assembled.<\/p>\n

Factory method<\/strong><\/h4>\n

“Define an interface for creating an object<\/strong>, but let subclasses decide which class to instantiate”<\/em>
\nPut a dedicated method to a class (Creator<\/em>) which creates the Product. Creator<\/em> also can contain other methods which is used with Product.<\/em> The subclass of Creator<\/em> will implement the method and create the specific Product<\/em> instance.<\/p>\n

Prototype<\/strong><\/h4>\n

Create new instances of a class using an existing one by cloning\/copying it. Very useful, when the creation of new instances needs in runtime while the classes are referenced by an interface\/base-class.<\/p>\n

Singleton<\/strong><\/h4>\n

“Ensure a class only has one instance, and provide a global point of access to it”
\n<\/em>Instance of a class can be accessed through only one method (a static\/class method) and keep the only instance inside the class scope. The allocation\/creation of the class instance have to be prohibited to other classes.
\nBe careful and do not overuse this pattern. This is one of the anti-patterns. For more information why, see here (http:\/\/andras.palfi.hu\/singleton-the-anti-pattern<\/a>).<\/p>\n

Structural Patterns<\/strong><\/h3>\n

Adapter<\/strong><\/h4>\n

Implement an interface for a class to make it compatible with another class which wants to use the first class.<\/p>\n

Class adapter: <\/strong>use multiple inheritance\/interface implementation to implement the new interface while subclassing the original class.
\nObject adapter: <\/strong>create a new class implementing the desired interface and encapsulate the original class holding reference to it in a member. In the interface-methods call the methods of the encapsulated class (see: delegation).<\/p>\n

Bridge<\/strong><\/h4>\n

“Decouple an abstraction from its implementation so that the two can vary independently”
\n<\/em>You have a class hierarchy which performs complicated operations. Each operation in a subclass calls the existing simpler operations referencing the operations through and interface. On the very bottom of this hierarchy there are some very simple operations. This very simple operations base to be delegated to another base class or interface so each call of the basic operations will be forwarded to another class. By subclassing this delegated class you will have complex operations using the class hierarchy while you only have to implement very simple methods. Reimplementing the basic operations in a separate class gives you a different representation of the complex hierarchy.
\nFor example: a drawing application which draws complex shapes (rect etc.) using the drawline <\/em>method on the very base. If you implement the drawline to different OS-s your complex drawing is still the same but works on different platforms.
\n<\/em><\/p>\n

Composite<\/strong><\/h4>\n

Compose objects to hierarchies by using a base class\/interface which contains the very basic mandatory operations to manage the hierarchy and perform basic operations.
\nYou will have node<\/em> classes and leaf<\/em> classes. Calling a basic operation on a node<\/em> will forward the same call to all its children. Hierarchy management operations will works only on node items.<\/p>\n

Decorator<\/strong><\/h4>\n

Attach additional functionality to an existing component<\/em> by wrapping it. For compatibility reason all the classes needs a base class\/interface. All operations called on the decorator<\/em> will be forwarded to the wrapped class but performing additional operations before and\/or after the forwarded call.<\/p>\n

Facade<\/strong><\/h4>\n

To hide<\/strong>, simplify<\/strong> or control<\/strong> a complex class hierarchy create and publish a new class. Delegate all operation to the appropriate subsystem class.
\nUsers of the facade<\/em> don’t know about the subsystem classes and subsystems classes don’t know about the facade<\/em> or the user classes.<\/p>\n

Flyweight<\/strong><\/h4>\n

Share the expensive objects between instances if there are numerous elements in a system which uses the same o almost the same classes. Do not store system-object specific states in the flyweights<\/em> but pass the actual state to them on use.<\/p>\n

Proxy<\/strong><\/h4>\n

A placeholder for an object to control the access to it. Wrap the original object into the proxy<\/em> and forward every call to it.<\/p>\n

remote proxy: <\/strong>provides a local representation of a remote object in a different address space.
\nvirtual proxy:<\/strong> create the wrapped object on demand – lazy binding
\nprotection proxy: <\/strong>filter the access to an object
\nsmart pointer: <\/strong>reference counting and lifetime management; thread locking<\/p>\n

Behavioral Patterns<\/strong><\/h3>\n

Chain of Responsibility<\/strong><\/h4>\n

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.<\/p>\n

Command<\/strong><\/h4>\n

Encapsulate a request as an object, thereby letting you parameterize<\/strong> clients with different requests, queue<\/strong> or log<\/strong> requests, and support undo<\/strong>able operations.<\/p>\n

Interpreter<\/strong><\/h4>\n

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.<\/p>\n

Iterator<\/strong><\/h4>\n

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.<\/p>\n

Mediator<\/strong><\/h4>\n

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interactions independently. The colleague objects don’t hold reference to each other but a reference to the mediator object (through an interface or abstract class). The mediator has reference to the more important colleague objects.<\/p>\n

Memento<\/strong><\/h4>\n

Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. Serialization\/deserialization.<\/p>\n

Observer<\/strong><\/h4>\n

Define a one-to-many dependency between objects. The observers<\/em> listen to the changes of observed object (subject<\/em>) so that when the subject<\/em> changes its state, all its observers<\/em> are notified and updated automatically.
\nUsually the subject<\/em> send out specific messages which the observers<\/em> catch\/handle.<\/p>\n

State<\/strong><\/h4>\n

Use if there is a need to change the behavior of a class in runtime. The client<\/em> class holds reference to the context<\/em> class which is technically a proxy. The context<\/em> class holds reference to a specific state<\/em> object. If the state should change the context<\/em> class sets its pointer to another state<\/em> class.<\/p>\n

Strategy<\/strong><\/h4>\n

Encapsulate specific functionality into classes with the same interface. This way different operations or functionalities will be interchangeable.<\/p>\n

Template method<\/strong><\/h4>\n

Implement an operation using more steps. The subclasses have to add implementation of certain steps. For example opening document.<\/p>\n

Visitor<\/strong><\/h4>\n

Perform different operations on an object hierarchy. Visitor base class declares VisittXXX operations for all ConcreteElements in the object hierarchy (VisitConcrete1, VisitConcrete2). The ConcreteVisitor classes overrides the VisitXXX methods to perform the necessary operations. The Element base class declares the Visit(Visitor) method which the ConcreteElement classes override and the their Visit methods will call the appropriate VisitXXX method. This way you can define and perform different operations on a hierarchy (composite, list, etc).<\/p>\n

Non GoF Patterns:<\/h3>\n

Multiton<\/h4>\n

Similar to singleton but usable for more different instances. A collection of singletons. Usually the different “singletons” can be access by a referencing key: string, enum, interface etc.<\/p>\n

\n

Principles<\/h2>\n

SOLID<\/strong><\/h3>\n

Solid is an acronym for the following principles.<\/p>\n

    \n
  • S<\/span>ingle Responsibility Principle:<\/strong> a class should have only a single responsibility<\/li>\n
  • O<\/span>pen Closed Principle:<\/strong> classes should be open for extension but closed for modification<\/li>\n
  • L<\/span>iskov Substitution Principle:<\/strong> derived classes must be substitutable for their base classes.<\/li>\n
  • I<\/span>nterface Segregation Principle:<\/strong> make fine grained interfaces that are client specific. Many client specific interfaces are better than one general purpose interface.<\/li>\n
  • D<\/span>ependency Inversion Principle: <\/strong>depend on abstractions not on concrete implementations. There are high level and low level objects. High level uses the low level. The concept is that the high level should specify the interface which should be implemented by the low level (the writer methods of a logging interface should come from the higher level object and not specified for example by the FileWriter which contains file level attributes\/properties)<\/li>\n<\/ul>\n

    Inversion of Control – IoC<\/strong><\/h3>\n

    Used to decouple different classes so the classes won’t reference each other but should use interfaces and will get the used instances on another way. (Belongs to the Dependency Inversion Principle)<\/p>\n

    Service locator\/provider:<\/strong><\/h4>\n

    Instead of referencing (and creating) objets of specific classes use a special class which provides the necessary classes on runtime. The service locator usually provides long live objects but also can behave like a factory (or better if it uses one). The service locator is a proper substitution of the singleton pattern.<\/p>\n

    Dependency injection – DI:<\/strong><\/h4>\n

    pass the dependent objects to the user class on runtime<\/p>\n

    Constructor injection:<\/strong> pass as a parameter of the constructor
    \nSetter injection: <\/strong>pass by calling a setter method
    \nInterface injection<\/strong>: interface declares a setter like logic and should override the original class.<\/p>\n

    Separation of Concerns<\/h3>\n

    TBD<\/p>\n

    GRASP<\/strong><\/h3>\n

    TBD<\/p>\n

    KISS<\/h3>\n

    TBD<\/p>\n

    DRY<\/strong><\/h3>\n

    TBD<\/p>\n

    YAGNI<\/h3>\n

    TBD<\/p>\n

    Other patterns, principles<\/h3>\n

    Closure<\/h4>\n

    Encapsulate sets of operations together with their context\/used variables. Usually in the background the compiler generates a tiny class for you.<\/p>\n

    Lazy load\/ Late binding<\/h4>\n

    TBD<\/p>\n

    RAII<\/h4>\n

    TBD<\/p>\n

    Opaque pointer\/Pimpl idiom<\/h4>\n

    TBD<\/p>\n

    Type Introspection<\/h4>\n

    The ability of a program to check\/get information of a class in runtime so the client<\/em> can make decisions and perform different operations depending on the information of the referenced class.<\/p>\n

    Reflection<\/h4>\n

    Type introspection + the ability to modify the structure and behavior of classes in runtime.<\/p>\n

    Presentation Patterns<\/h2>\n

    Model-View-Controller<\/strong> – MVC<\/strong><\/h3>\n

    Controller has reference to the View and the Model, View can have a reference to the Model,<\/p>\n

    Model-View-Presenter<\/strong> – MVP<\/strong><\/h3>\n

    Presenter has reference to the View and to the Model. The view doesn’t have reference to the model or to the Controller<\/p>\n

    Passive View<\/strong> – MVP PV<\/strong>: the view no longer responsible for updating itself from the model.<\/p>\n

    Supervising Presenter<\/strong> – MVP SC<\/strong>: view uses some form of Data Binding to populate much of the information for its fields, for complex interactions then the controller steps in.<\/p>\n

    PM<\/strong><\/h3>\n

    View has reference to the Presenter (presentation model), it doesn’t know about the view. Presentation model fires events what are handled by the View.<\/p>\n

    MVVM<\/strong><\/h3>\n

    PM with data binding.<\/p>\n

    \n","protected":false},"excerpt":{"rendered":"

    Introduction This article is a cheat sheet of the most used design patterns and principles. This was not made to teach you. This was made to make you remember what you already understood. Basic definitions Several design patterns based on the following Wrapper Hold a reference to another object. Sometimes it means the owner manages […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"hide_page_title":"","footnotes":""},"categories":[20,3,8],"tags":[],"_links":{"self":[{"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=\/wp\/v2\/posts\/13"}],"collection":[{"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=13"}],"version-history":[{"count":0,"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=\/wp\/v2\/posts\/13\/revisions"}],"wp:attachment":[{"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=13"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=13"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andras.palfi.hu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}