Introduction to Design Patterns

What are Design Patterns?

What is a Pattern?

Patterns exist everywhere in the world. In culinary, art, medicine, law, mathematics, music, dancing and the list goes on. Genrally, a pattern is identified as a recurring arrangement created to solve some generalized problem. It is simply a solution outline. That solution outline can be used over and over again when registered as a viable option to a repeatable problem. In more formal words, a pattern is a generalized outline of a reusable solution to a recurring problem.

Why Design Patterns?

Have you ever came across situations where the same problem occurs at multiple times while you are coding? A lot of developers around the world face the same problem in daily coding struggle. Equally, there are many solutions out there to identify general iterative problems in development and designing software systems. Design Patterns are the most popular and standard solutions for those recurring problems.

Who Invented the Concept?

Even though billions of people use the idea to solve many problems across the world,  a person has defined, encapsulated best practices and found a global standard for design patterns. Christopher Alexander from Austria is a building architect and a civil engineer. He came up with creative solutions to recurring construction issues where building engineers are obsessed with. Which was published as A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977) which provides patterns for architecting successful buildings and towns.

Alexander’s definition of the Pattern,

Each pattern describes a problem which 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.

This is the central idea where software scientists were getting inspired to invent software design patterns.

What is GOF?

GOF stands for Gang of Four, in the software field, they are the super heroes who invented the precious concept of design patterns. If not, designers and developers are still wondering here and there wasting time and effort to find various solutions to recurring problems. The gang is Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The final deliverables are encapsulated and finely documented into the book Design Patterns: Elements of Reusable Object-Oriented Software which is supported by Addison-Wesley in 1995

What is a Software Design Pattern?

Software design pattern is a known, formal way to solve common coding difficulties. In more formal words, it is an identified and proven solution template to a recurring problem in a particular software context. Most of the software design pattern and well defined and pre-evaluated. In software designing real world, the components are identified as objects oriented terms. Hence, most of the design patterns are illustrated via class, object, interface relationships and their inter-communication behaviors.

The most important thing to remember is these design patterns are not finalized solutions which can be transformed directly into the code. Those are just templates or outlines for resolving problems. That template can be utilized in various situations in designing and implementing software systems. It is simply a proposed generalized solution to consume in an ad-hoc manner using our code samples.

In Object Oriented Style

Design patterns are based on object oriented concepts, hence it’s easier to use with languages which based on OOP. Different OOP languages possess different mechanisms to apply patterns. In object oriented terms, like a class is a blueprint of an object and object provides the actual implementation, a design pattern is the blueprint represent the conceptual design while actual implementation will be the instance of that design pattern, which is customized to individual usage.

Why are Design Patterns essential in Software Design?

Design patterns are essential when designing complex systems. Engineers and architects rely heavily on design patterns when the problem domain is getting serious. The most complex and profound anomalies can be addressed via identified design patterns without wasting valuable time. Let’s learn why everybody likes design patterns this much,

  • Provide a solution template for a pre-identified, time-consuming and recurring problem. Since the problem was analyzed thoroughly and solutions are applied successfully, people who use that pattern need not worry about unexpected and inaccurate results. Simply, there is no re-inventing the wheel part for the defined design patterns.
  • Help to design and implement new systems without spending a long time and resourcefully.
  • Ability to extend and modify the codes without much difficulty which improves the maintainability of the system
  • Well documented common terminology for every pattern makes it easy to refer at any point. It will make any discussions and analysis easier which also improves the individual and team learning.

Main Components of a Design Pattern

Likewise, every concept or idea, design pattern also made up of the main set of components to clearly define its usage and existence in the software world. A design pattern is a predefined template which is formed using four main building blocks. These building blocks could be represented as the elements of the proposed template. Following four elements gather to create a meaningful design pattern to solve a recurring software problem.

Pattern Name

Every documented design pattern has a name. The pattern name act as the identifier for the design pattern. This typically denotes the design problem and solution in short terms, and it helps the ability of easy reference within the community providing a common vocabulary for software professionals.

The Problem

This is the part which addresses the nature of the design problem and its applicability. The regarding pattern could be valid in any situation where the identified and generalized problem occurs. It helps to derive when to apply the pattern by describing the problem and its context. The problem might include a set of conditions to meet before applying the pattern in certain scenarios.

The Solution

This is the part which describes the answer to the design problem. This is not the complete code snippet, but a template with guidelines to apply codes from our context. The solution includes the individual elements that generate the design, the relationships of each element, responsibilities, and collaboration to derive the solution. Hence, all those elements work together to solve the design problem.

The Consequences

This is the component which focuses on result and tradeoffs of the applied design pattern. There could be various types of results when applying a design pattern like system’s flexibility, extensibility, and portability. Most concerning consequences would be space and time trade-offs. These consequences are essential in evaluating design alternatives and figuring out the cost and benefits of pattern application. This feature enables the space to compare the design patterns to analyze a different better solution for the actual problem.

Elements which form a Design Pattern Template

Since a design pattern is a solution template for a recurring problem, that template should have the basic elements to build itself. These set of elements forms a format for the pattern template. The template creates a uniform structure for the proposed solution enabling easy learning, comparison, and usage of a pattern. Together, following elements will generate a viable solution for your design problem.

Element Usage
Name Give an identity to the pattern
Intent/Purpose What does the design pattern do or what is the design issue it will address
Context The general situation which the pattern to be applied
Forces The issues or concerns to consider when applying the pattern
Solution The recommended method to solve the problem in the given context
Consequences What are the results and trade-offs of applying the pattern and space to adjust independently
Implementation What techniques, rules and language concerns to consider when coding the pattern
Related Patterns A list of related or similar patterns
Sample Code Code snippet to get the idea of the implementation
Known Uses Examples of the patterns in real system

Real world example,

Problem: You love to have one chocolate sauce with almost all of your milk and cream related desserts

Context: When you are at your home or having a picnic

Forces: You can’t make it from the scratch whenever a dessert shows up

Solution: Make a large jar of chocolate sauce and keep it refrigerated to use when needed

Consequences: Chocolate sauce may expire after 3 – 4 months

Types of Design Patterns

 

Types of Design Patterns
Types of Design Patterns

Creational Patterns

This category provides patterns to resolve the problems of object creation in flexible ways. These will eliminate the difficulties in object instantiation and configuring classes

Structural Patterns

This category provides patterns to resolve the problems of object structure and composition. These will help to form accurate relationships between classes, object and interfaces

Behavioral Patterns

This category provides patterns to resolve the problems of object interaction and communication. These will use to manage algorithms, relationships and responsibilities between objects

How are the Design Patterns categorized?

Since there are many design patterns to be aware of, it’s essential to arrange those to refer and find easily. Design patterns are classified according to two criteria. One is the purpose of the pattern and the other is the scope of the pattern. Purpose highlights what a pattern does while scope specifies whether the pattern applies primarily to classes or to objects. Let’s view the standard pattern classification.

 

Design Pattern Classificaion
Design Pattern Classification

List of Properties of a Good Design Pattern

  • Provide a common vocabulary to refer to, for the general audience
  • Compact yet elaborative to effectively communicate complex principles
  • Make the software design and architecture easy to document
  • Present more than one solution path
  • Capture essential elements of a software design in solid forms

Patterns Don’t

  • Provide an exact solution to any particular problem. The person who is interested at that moment should observe the template and derive the personalized implementation at the time of design or implementation
  • Solve all the design problems in the world. These are a handful of patterns which are identified in the past and still there are newer patterns are emerging and getting added to the software world.

Special Notes

  • Most patterns are not tightly coupled with any specific language, platform or any API
  • Most of the software design patterns demands the flavor of OOP concepts in implementation while some can be used in non-object oriented context
  • There might have various options to implement one design pattern like you can use an interface or abstract class to implement one approach and you can use ‘Is-A’ or ‘Has-A’ relationship to define any links within objects depending on the situation
  • Most of the patterns can be implemented in various frameworks and languages like Java, C#, VB etc.
  • There are patterns apart from OOP context which focuses on building multithreaded applications, parallel processing, securing information systems, handling complex databases and much more

Summary

Design Patterns are still adding to the software field, and there are many more popular patterns in the community. This article illustrates the basic set of patterns introduced by Gang of Four in Design Patterns: Elements of Reusable Object-Oriented Software book. Learning design patterns is essential to stay unbeaten in within the experts. So, start learning from today if you are not still on the move.

 

4 thoughts to “Introduction to Design Patterns”

  1. Be careful while using a design pattern. You should weigh the pros and cons of each pattern before you decide to use one. It may not make sense to use some patterns in smaller projects where the cons will outweighs the pros for a design pattern. You may end up with uncessay code like factories while you are only creating one object. So, evaluate your design patterns before using them.

    1. You are right. Choosing a design pattern should be done carefully. Pros and cons need to be looked at to see if a pattern fits a problem. People should also be carful about the anti patterns

Leave a Reply