In software development, wherever you work, whatever language you are programming in or whatever you’re building, CHANGE is the friend that will be with you always.
With inexperienced developers, they tried to write code that helps their software adapts to these changes temporarily without bothering about the reusable, extendable and maintainable ability of it should the next probable changes occur. This manner of approach leads to their having to spend a lot more time on the maintenance phase. If worst comes to worst, they will have to rebuild the software project they are handling on completely from the beginning. That’s the reason why Design Patterns was born to save the world.
What is Design Patterns?
You can find a bunch of definition about design patterns on the Internet. From my real-world experience as a software developer, I can simply say that design patterns are just solutions to common occurring problems in software design. Instead of providing a finished design that can be brought into your code, they are just available templates showing you how to address these problems effectively.
Each design pattern has four essential elements in general:
- Pattern name: The handle we can use to describe a design problem, its solutions, and consequences in a word or two.
- Problem: The situations when we should apply the pattern.
- Solution: The ins and outs of the design including its elements, their relationships, responsibilities, and collaborations.
- Consequences: The results and trade-offs of applying the pattern.
Benefits of Using Design Patterns
There are a number of benefits that design patterns bring about:
- With carefully tested and proven development paradigms, design patterns can help speed up your software development process. Instead of tearing your hair out trying to come up with a suitable design by yourself, just find a design pattern that match your requirements and apply it.
- Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- Design patterns provide general solutions, documented in a format that doesn’t require specifics tied to a particular problem.
- Design patterns allow ease of communication between software developers.
Classifying design patterns
According to the book called Design Patterns – Elements of Reusable Object-Oriented Software of the Gang of Fours (GoF), the authors classified 23 design patterns into three main categories: Creational Patterns, Structural Patterns and Behavioral Patterns.
As a developer, we spend most of our time on creating classes and objects. Those patterns below can be used to get the job done effectively.
|Abstract Factory||Creates an instance of several families of classes.|
|Builder||Separates object construction from its representation.|
|Factory Method||Creates an instance of several derived classes.|
|Object Pool||Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.|
|Prototype||A fully initialized instance to be copied or cloned.|
|Singleton||A class of which only a single instance can exist.|
If you want to form larger structures from different classes and objects as well as provide new functionalities to them, structures design patterns are all what you need. They consist of the following patterns:
|Adapter||Match interfaces of different classes.|
|Bridge||Separates an object’s interface from its implementation.|
|Composite||A tree structure of simple and composite objects.|
|Decorator||Add responsibilities to objects dynamically.|
|Facade||A single class that represents an entire subsystem.|
|Flyweight||A fine-grained instance used for efficient sharing.|
|Private Class Data||Restricts accessor/ mutator access.|
|Proxy||An object representing another object.|
Behavioral design patterns really come into play if you want to deal with communication between objects. They consist of the following patterns:
|Chain of Responsibility||A way of passing a request between a chain of objects.|
|Command||Encapsulate a command request as an object.|
|Interpreter||A way to include language elements in a program.|
|Iterator||Sequentially access the elements of a collection.|
|Mediator||Defines simplified communication between classes.|
|Memento||Capture and restore an object’s internal state.|
|Null Object||Designed to act as a default value of an object.|
|Observer||A way of notifying change to a number of classes.|
|State||Alter an object’s behavior when its state changes.|
|Strategy||Encapsulates an algorithm inside a class.|
|Template Method||Defer the exact steps of an algorithm to a subclass.|
|Visitor||Defines a new operation to a class without change.|
In brief, Design patterns plays a major part in software development. It helps speed up our software development process by providing tested, proven development paradigms.
However, to be able to decide which design pattern is appropriate for your software project requires a considerable amount of studying time and real-world experience.
In the next post of this series, I will focus on our first design pattern – the Factory Method Pattern.
For further reading:
- Design Patterns – Elements of Reusable Object-Oriented Software
- What is Design Patterns?
- Object Pool Pattern – when and how to use it in PHP?