Software design pattern is a description and an explanations of a general software design problem and its solution. It describes the whole situation for the problem, when and how to solve it and the solution impacts in an accepted standard way. It is not piece of code we can use it directly and not specific for a programing language but very similar to description or template of repeated solution. if design pattern used correctly and in the right place it will be the most effective solution but on the other hand if used in inappropriate ways it become the problem not the solution.
History of patterns originated as an architectural concept by Christopher Alexander (1977/79). But design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 by the so-called ‘Gang of Four’ (‘GoF’), which discuss 23 software design patterns, after that a lot of counterarguments was made that it depends on the programming language and in some of these languages can be able to eliminate the need for the majority of these patterns. Most of new languages was adopted built in solution for most of these patterns, while others remain unnecessary.
We learn about design pattern so that we can solve software design problem in tried-and-true ways. Patterns are about reusable designs and interactions of objects. Because these designs are tried and tested, they can be relied upon to improve the development process. By using them, they can help avoid problems at a later stage of development because they address problems that can only be observed when the implementation is completed or in its later stages. Using patterns in the right place and time will speed up development process.
Usage of Design Patterns can be one of two, common platform for developers by providing a standard terminology and are specific to particular situation or as best practices because it provides the best solutions to problems found in the development process and it has improved over time also It offers a quick and easy way to learn and involve in software design.
Complexity of the code also can be reduced for anyone familiar with this wide used patterns. By well-known and well-understood patterns developers can communicate, transfer knowledge and solutions easily but some design patterns can harm performance and complicating the resulting designs by adding unnecessary levels of lack of straightforwardness in action. Common design patterns can be improved over time, making them more robust less complex.
Software design patterns by classification
Based on their use modern design patterns are classified to four categories:
‘ Creational Patterns
Ordinarily these patterns provide techniques of objects creation and its create process, they create the object automatically based on the current situation and needs for this case. this type can be split into class-creation which use inheritance effectively in the instantiation process and object-creational which use delegation effectively to get the job done.
Patterns in this category are: Abstract factory, Builder, Dependency Injection, Factory method, Lazy initialization, Multiton, Object pool, Prototype, Resource acquisition is initialization (RAII) and Singleton.
‘ Structural patterns
Generally structural patterns about relationships between objects, how easily work with each other’s and comprises various objects to obtain new functionality or to form larger structures.
Patterns in this category are: Adapter (Wrapper or Translator), Bridge, Composite, Decorator, Extension object, Facade, Flyweight, Front controller, Marker, Module, Proxy and Twin.
‘ Behavioral patterns
Concentrated on how objects are behave and communicate to each other’s.
Patterns in this category are: Blackboard, Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null object, Observer (Publish-subscribe), Servant, Specification, State, Strategy, Template method and Visitor.
‘ Concurrency patterns
A concurrency pattern addresses some aspect of multithreaded programming, produce, store and consume thread. ‘Concurrency is the composition of independently executing computations. Concurrency is not parallelism, although it enables parallelism. If you have only one processor your program can still be concurrent but it cannot be parallel.’,
Patterns in this category are: Active Object, Balking, Binding properties, Blockchain, Double-checked locking, Event-based asynchronous, Guarded suspension, Join, Lock, Messaging design pattern (MDP), Monitor object, Reactor, Read-write lock, Scheduler, Thread pool and Thread-specific storage.
The previous lists have many commonly used and some less commonly used software design patterns and are not exhaustive and of course other types of design patterns are existing like architectural, organizational, and communication patterns.
‘ Other patterns
There are many design patterns not included in the previous lists like: Business delegate, Composite entity, Dependency injection Intercepting filter, Lazy loading, Mock object, Type tunnel, Method chaining, Interceptor, MVC, ADR, ECS, n-tier, Publish’subscribe, Naked objects, Service locator, Active record, Identity map, Data access object, Data transfer object, Inversion of control, Model 2.
Most common patterns and their use
– Singleton: Used when need an object that only needs to be instantiate once.
– MVC: It divides a given application into three interconnected parts model, view and controller. This is done to separate internal representations of information from the ways information is presented to, and accepted from, the user. The MVC design pattern decouples these major components allowing for efficient code reuse and parallel development.
– Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it. Capture the abstraction in an interface, bury implementation details in derived classes.
– Layers (n-tier): In which presentation, application processing, and data management functions are physically separated. N-tier application architecture provides a model by which developers can create flexible and reusable applications. By segregating an application into tiers, developers acquire the option of modifying or adding a specific layer, instead of reworking the entire application. A three-tier architecture is typically composed of a presentation tier, a domain logic tier, and a data storage tier.
– Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
– Factory method: Define an interface for creating a single object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
– Proxy: An object representing another object. Provide a surrogate or placeholder for another object to control access to it.
– Builder: Used when need to separates object construction from its representation.
– Template method: Defines 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.
– Iterator: Enables developers to access the elements of an aggregate object sequentially without exposing its underlying representation.
– Observer: Defines a one-to-many dependency between objects where a state change in one object results in all of its dependents being notified and updated automatically. Observer is also known as the Publish-subscribe pattern.
– Composite: Composes objects into tree structures that represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
– ServiceLocator: used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the “service locator”, which on request returns the information necessary to perform a certain task.
– Data Accessor Object (DAO): It provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, the DAO provides some specific data operations without exposing details of the database
– Data Transfer Object (DTO): is an object that carries data between processes. The motivation for its use is that communication between processes is usually done resorting to remote interfaces (e.g. web services), where each call is an expensive operation.
– Chain of Responsibility: A way of passing a request between a chain of objects by 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.
– State: Alter an object’s behavior when its state changes. The object will appear to change its class.
New issues related to design patters in recent publications
Pattern development, pattern mining, and pattern usage are the most active topics in the field of design patterns. Finding if the presence of the design patterns is linked to the presence of code smells, and to identify the relationships between individual patterns and code smells. New classifications for the patterns. Apply and adding new design patterns and improve these new patterns.
Conclusion
When you use these design patterns, always make sure that you’re trying to solve the correct problem. As I mentioned previously, these design patterns are a double-edge sword: if used in the wrong context, they can potentially make things worse; but if used correctly, they become indispensable. Design patterns are, by principle, well-thought out solutions to programming problems. Many programmers have encountered these problems before, and have used these ‘solutions’ to remedy them. If you encounter these problems, why recreate a solution when you can use an already proven answer?
References
– Alexander Shvets (2001). Design Patterns Explained Simply. Sourcemaking.com.
– B.Bafandeh Mayvana, A.Rasoolzadegana and Z.Ghavidel Yazdib (2017). The state of the art on design patterns: A systematic mapping of the literature. Journal of Systems and Software.
– Jeff Friesen (2012). Design patterns, the big picture, Part 1: Design pattern history and classification. Available at: https://www.javaworld.com/article/2078665/core-java/design-patterns–the-big-picture–part-1–design-pattern-history-and-classification.html.
– Jason McDonald (2008). Design Patterns. DZone communities.
– Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (1997). Design Patterns, Elements of Reusable Object-Oriented Software.
– Gabriel (1996), Richard. Patterns of Software: Tales From The Software Community (PDF). Oxford University Press.
– Wikipedia (2017). Software design pattern. Available at: https://en.wikipedia.org/wiki/Software_design_pattern
– Tutorialspoint. Design Pattern ‘ Overview. Available at: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm
– tutsplus. A Beginner’s Guide to Design Patterns. Available at: https://code.tutsplus.com/articles/a-beginners-guide-to-design-patterns–net-12752
– geeksforgeeks. Design Patterns. Available at: http://www.geeksforgeeks.org/design-patterns-set-1-introduction/
– thedevpiece. 8 design patterns that every developer should know. Available at: http://www.thedevpiece.com/design-patterns-that-every-developer-should-know/
– David Kocher (2011). Concurrency Patterns. Institut f ”ur Informatik, Available at: https://sudo.ch/unizh/concurrencypatterns/ConcurrencyPatterns.pdf
– golang. Go Concurrency Patterns. Available at: https://talks.golang.org/2012/concurrency.slide