In software engineering, a design pattern is a general repeatable, reusable solution to a commonly occurring problem in software design. Modern software development has to be opened to fast and frequent changes in business requirements, future extensions and easy in maintaining. But in which way achieve these goals? This isn’t the simple process. However, since every professional developer wants good quality his software many problems have already been encountered. Based on common difficulties have been proposed good solutions. Find our way could be satisfying, but time-consuming. We can learn from the experience of others and don’t reinvent a wheel again.
There is a list with most popular and commonly used patterns cataloged by for authors often called Gang of Four (GoF). This list contains around 23 patterns. Let’s have a fast look on each one. The GoF design patterns are classified into three categories:
These design patterns provide a way to create objects separating implementation of creation from the rest of system. This pattern may concern class creating and object creating.
- Abstract Factory – creates an instance of several families of classes, provide an interface for creating families of related or dependent objects without specifying their concrete classes
- Builder – separate the construction of a complex object from its representation, allowing the same construction process to create various representations, allows a better control over the construction process
- Factory Method – defines an interface for creating objects, but let subclasses to decide which class to instantiate and refers to the newly created object through a common interface.
- Prototype – create objects based on a fully initialized, specified instance (template) that can be copied or cloned
- Singleton – ensure a class has only one instance and provide a global point of access to it
If you need to build large structures by using an existing set of classes or objects you should get to know these patterns. They also can be further divided into class composition pattern and object composition pattern.
- Adapter – match interfaces of different classes, lets classes work together that could not otherwise because of incompatible interfaces.
- Bridge – separates an object’s interface from its implementation, decouple an abstraction from its implementation allowing the both to vary independently
- Composite – compose objects into tree structures to represent part-whole hierarchies
- Decorator – attach additional responsibilities to an object dynamically keeping the same interface, decorators provide a flexible alternative to subclassing for extending functionality
- Facade – provide a unified interface to a set of interfaces in a subsystem, Facade defines a higher-level interface that makes the subsystem easier to use
- Flyweight – use sharing to support large numbers of similar objects efficiently
- Proxy – provide a surrogate or placeholder for another object to control access to it
These design patterns are used to manage communication between objects.
- Chain of Resp – 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 with the chain until an object handles it
- Command – encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests and the queuing or logging of requests, it also allows for the support of undoable operations
- Interpreter – given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language
- Iterator – provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation
- Mediator – 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 allows their interaction to vary independently
- Memento – without violating encapsulation, capture and externalize an object’s internal state allowing the object to be restored to this state later
- Observer – define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
- State – allow an object to alter its behavior when its internal state changes, the object will appear to change its class
- Strategy – define a family of algorithms, encapsulate each one, and make them interchangeable, Strategy lets the algorithm vary independently from clients that use it
- Template Method – Defer the exact steps of an algorithm to a subclass, define the skeleton of an algorithm in an operation, deferring some steps to subclasses, Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure
- Visitor – represent an operation to be performed on the elements of an object structure, Visitor lets a new operation be defined without changing the classes of the elements on which it operates
The design patterns are powerful tools in developer’s hands, but we must remember that will be used in right places for them and in right way. It is often the problem with design patterns because they provide general solutions and we must decide that using a particular design is a good choice. If we use them properly in our software design patterns allow to reduce errors, provide better communication, architecture and code readability, that help you deal with future extensions and modifications and of course development time will speed up.
– a book “Design Patterns: Elements of Reusable Object-Oriented Software“