A design pattern is the re-usable form of a solution to a design problem. The idea was introduced by the architect Christopher Alexander and has been adapted for various other disciplines, most notably computer science.
Software design patterns
Software design patterns are proposals for general solutions that have been developed to solve similar problems frequently encountered during software design. Although software design patterns are generally defined independently of programming languages, software design patterns suited to object oriented programming languages are more commonly known. These patterns show the relationships and interactions between objects and classes. The programmer can customize a design pattern by looking at the problem in his hand.
Details
An organized collection of design patterns that relate to a particular field is called a pattern language. This language gives a common terminology for discussing the situations designers are faced with.
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher Alexander
Documenting a pattern requires explaining why a particular situation causes problems, and how the components of the pattern relate to each other to give the solution. Christopher Alexander describes common design problems as arising from “conflicting forces” — such as the conflict between wanting a room to be sunny and wanting it not to overheat on summer afternoons. A pattern would not tell the designer how many windows to put in the room; instead, it would propose a set of values to guide the designer toward a decision that is best for their particular application. Alexander, for example, suggests that enough windows should be included to direct light all around the room. He considers this a good solution because he believes it increases the enjoyment of the room by its occupants. Other authors might come to different conclusions, if they place higher value on heating costs, or material costs. These values, used by the pattern’s author to determine which solution is “best”, must also be documented within the pattern.
Pattern documentation should also explain when it is applicable. Since two houses may be very different from one another, a design pattern for houses must be broad enough to apply to both of them, but not so vague that it doesn’t help the designer make decisions. The range of situations in which a pattern can be used is called its context. Some examples might be “all houses”, “all two-story houses”, or “all places where people spend time”.
For instance, in Christopher Alexander’s work, bus stops and waiting rooms in a surgery center are both within the context for the pattern “A PLACE TO WAIT”.
Design patterns classes
The Quadruple Gang’s Design Patterns book (ISBN 0-201-63361-2) distinguishes three patterns of design patterns, but there is no sharp criterion that separates them from each other.
Creation patterns
Creation patterns provide suggestions on how to create software objects (or in other words, class instances). The idea is that a good software must be designed independently of how the objects it contains are created. In other words, where and how objects are created does not affect the operation of the software they belong to; new features should not be added and problems with the changes.
As software systems evolve, object composition gains more importance than class inheritance. The reason for this is that designs based on defining simple basic behavior patterns for software systems are more flexible than designs based on fixed behavior. In other words, adding behaviors to objects as a combination allows later behavior to be modified according to the development of the software. In this case, a design based on the basic behavioral requirements for the developed software makes it possible to use different or more complex behaviors without modifying the object interfaces.
However, it is more difficult to sample objects that provide basic behavior through objective combinations, or to create objects from derived classes by inheriting or altering behavior. Creation patterns include software patterns that can be used to overcome these difficulties.
Creation patterns store in the software system which concrete classes are used in the object instance as well as how these instances are created and assembled.
Factory method
By inheriting how the object creates it under the single interface used for object creation, it leaves the object creation functions in the interface by leaving it to the subclasses.
Example (prototype pattern)
When creating objects from complex and / or expensive classes, they allow new objects to be created by sampling from their existing ones instead of being created from the beginning. In this way, new objects are easily created and resources are not unnecessarily occupied.
Abstract factory pattern
A single interface makes it possible to create an object family on different platforms. This numbered software application can be moved to different platfroms without any behavioral changes. The abstract factory pattern keeps which concrete classes are used under a single interface.
Builder pattern
It allows a complex group of objects to be created in pieces as needed through a single interface. As the user uses the object group, the object group is structured in the required direction. Unused parts are created unnecessarily and do not expend resources.
The singleton pattern
In a class, only one object is created to be created. This object can be accessed from anywhere in the application. The object may not be created until it is used for the first time.
Structural patterns
It provides suggestions that allow building of wider software structures by combining structural pattern classes and objects. Class structure patterns and object structure patterns are divided into two.
Class structure patterns extend constructs by using class inheritance or compounding applications. Object structure patterns show how to combine objects to gain new functions.
Composite pattern
It allows objects to be combined together in a piece-whole relationship with a tree structure, and this compound can be reached from a single interface. The compound structure can expand and contract over time by adding and removing new objects.
Facade (facade pattern)
It allows a complex structure to be used together in a single interface.
Decorator pattern
It allows an object to add new responsibilities without changing the object. It makes it possible to improve the functionality of objects without subclassification.
Bridge pattern
It allows both the interface and the concrete implementation to be separated from one another. Changing the interface does not affect the interface. Both can be developed independently.
Flyweight pattern
Instead of creating a large number of similar objects, it allows the creation of a crowded object structure by creating visual objects from an example object. State variables of visual objects are stored by the user, not by the object itself.
Adapter pattern
It is used to adapt the interfaces of objects or classes from different sources.
Proxy pattern
It is possible to imitate the interface to use complicated, expensive, and difficult to build objects. It allows the orientation of the physical object of the object to be used to be hidden from the user.
Behavior patterns
Behavioral patterns provide suggestions on how functional responsibilities can be assigned between objects and how the solution methods required by the software can be used objectively. Behavioral patterns also provide objects and class patterns, as well as patterns related to communication between objects. Behavioral patterns allow the designer to concentrate on communication and communication methods between objects.
Behavioral patterns are also divided into two, just as they are in structural patterns: class behavior patterns and object behavior patterns.
Class behavior patterns enable behavior to be distributed among classes using inheritance. Object behavior patterns make it possible to achieve behavior through an object group that can not easily be achieved by a single object through object composition.
Mediator pattern
Objects connected with each other can be guided from a single point (that is, by the finder) under the same roof. Objects connected to the search finder communicate status changes to the search finder. The finder finds requests from objects related to editing and ordering required by the application. Top-level user objects only connect to the finder.
State pattern
It allows an object to change its behavior according to its situation. From the user’s perspective, it gives the impression that you are modifying the object class. It allows new behaviors to be added and removed in the direction required by the application. User objects are not affected by such changes.
Observer pattern
It allows a group of objects, observers, to be automatically informed of changes in an observed object. The object under observation continues to function independently of who is being tracked. It is possible for new observers to participate or leave in time. In this way the application can change behavior over time.
Template method pattern
It allows a procedure to be used as a solution template. It makes it possible for some processing steps on the die to be processed by subclasses. Therefore, some intermediate steps can be changed without changing the main pattern. Users are not aware of these changes.
Command pattern
It makes it possible for user (objective) requests to be transformed into objects and processed. In this way, the wishes of different users can be converted into objective records and kept in queues or records. It is also possible to reverse the transactions made on this vault.
Responsibilities chain (chain of responsibility pattern)
A user (objective) allows the request to be evaluated by multiple objects to be met. the user transmits the request through a single interface. Requests are tackled in turn by the objects connected to the request. The request is transferred from one object to another on the chain until it is welcomed. It is possible to add or remove new objects in the chain over time. The user is not affected by the interface from such changes.
Interpreter pattern
The pseudo-language defined to fulfill the requirements of complex applications is an interpreter template. Pseudo-language allows grammatical rules to be easily applied by defining them as classes. Since grammar rules are defined as classes, they can be easily modified and improved.
Yadigâr (memento pattern)
Yadigâr is used to hide the states of objects that play important roles in the application software and to remind or remind them when necessary.
Iterator pattern
It ensures that objects located under a mass object (Aggragate Object) can be reached in sequence, regardless of how objects are represented or realized. Objects represented in this way can be accessed via a single interface.
Strategy (strategy pattery)
Under the same interface, many solution methods that can solve the same problem hide the class, making it possible to satisfy requests of user objects without being aware of which method is used. The user is faced with different forms of behavior when they claim that they are working with the same kind of object.
Visitor pattern
It allows new operations to be added on a compound structure. The visitor visits individual objects within the compound structure, collects the necessary information, processes it, and presents it to the user.
Source From Wikipedia