What are Design patterns ?
In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. 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.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn’t require specifics tied to a particular problem.
In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.
To summarize, all design patterns have the following characteristics …
- A name
- A description of the problem being addressed
- A description of the solution
- An evaluation of the pattern’s consequences (i.e. its trade-offs)
As software developers and architects, why should we care about design patterns?
- Design patterns provide a common vocabulary, and therefore facilitate communication.
- Design patterns provide templates or guidelines for solving common design problems.
- Design patterns help us understand the consequences of our design decisions.
Main categories of design patterns?
There are three basic classifications of patterns Creational, Structural, and Behavioral patterns.
Creational Patterns (all about creation of objects)
- Factory Method: – Creates an instance of several derived classes.
- Abstract Factory: – Creates an instance of several families of classes.
- Builder: – Separates object construction from its representation.
- Prototype: – A fully initialized instance to be copied or cloned.
- Singleton: – A class in which only a single instance can exist.
- Adapter:-Match interfaces of different classes.
- Bridge:-Separates an object’s abstraction from its implementation.
- Composite:-A tree structure of simple and composite objects.
- Decorator:-Add responsibilities to objects dynamically.
- Façade:-A single class that represents an entire subsystem.
- Flyweight:-A fine-grained instance used for efficient sharing.
- Proxy:-An object representing another object.
- Mediator:- Defines simplified communication between classes.
- Memento:-Capture and restore an object’s internal state.
- Interpreter: – A way to include language elements in a program.
- Iterator:-Sequentially access the elements of a collection.
- Chain of Resp: – A way of passing a request between a chain of objects.
- Command:-Encapsulate a command request as an object.
- State:-Alter an object’s behavior when its state changes.
- Strategy:-Encapsulates an algorithm inside a class.
- Observer: – A way of notifying change to a number of classes.
- Template Method:- Defer the exact steps of an algorithm to a subclass.
- Visitor:- Defines a new operation to a class without change.
Deep dive in design patterns?
- Creational Patterns (all about creation of objects)
- Structural Patterns
- Behavioural Patterns
Final notes:
I think patterns as a whole can help people learn object-oriented thinking: how you can leverage polymorphism, design for composition, delegation, balance responsibilities, and provide pluggable behavior. Patterns go beyond applying objects to some graphical shape example, with a shape class hierarchy and some polymorphic draw method. You really learn about polymorphism when you’ve understood the patterns. So patterns are good for learning OO and design in general.
A lot of the patterns are about extensibility and reusability. When you really need extensibility, then patterns provide you with a way to achieve it and this is cool. But when you don’t need it, you should keep your design simple and not add unnecessary levels of indirection.
Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can’t afford to speculate what else it should do. We need to really focus on what it needs. That’s why I like refactoring to patterns.
