A Series on Design Patterns

Let us discuss time-tested solutions to recurring design problems in this article:

What is 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 a way that you can use this solution a million times over, without ever doing it the same way twice.”

— Christopher Alexander

Patterns provide a framework that can be applied to similar issues but may be solved in different ways, sometimes in real world and other times in digital space.

Design patterns are reusable solution to commonly occurring problem within a given context in Software design. It’s not a finished design that can be transformed directly into app. Rather, it is a template to solve a recurring design problem in code.

The pattern is not a specific piece of code, but a concept for solving a particular problem.

How Patterns Originated?

The concept of patterns was first described by Christopher Alexander, a Civil Engineer in A Pattern Language: Towns, Buildings, Construction book. Chris wrote about his experience in solving design issues related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect. He documented and published the experience he gained so that others could benefit.

In 1995, the idea was picked up by authors in book, Design Patterns: Elements of Reusable Object-Oriented Software, in which they applied the concept of design patterns to programming. The book featured 23 patterns solving various problems of object-oriented design, the book is well known by name “the GoF book”.

Why it became essential part of Software development?

• Design patterns are solutions to common problems in software design. It focuses on how to solve all sorts of problems using principles of object-oriented design
• It defines a common language which makes communication easy in software industry.
• The solution facilitates the development of highly cohesive modules with minimal coupling, makes the overall system easier to understand and maintain.

Are Design Patterns and Architecture Patterns same?

No, Architecture of an application refers to the larger structure of application while a design pattern refers to a method of solving a specific type of problem, much more focused and lower level than the global structure of the system. For example, a design pattern can be a solution to the problem of an object’s behaviour depending on its internal state, or how the object should be created after applying some rules/validations. With architectural level design, you are concerned with how to structure all the pieces together.

_ Architecture focuses on the abstract view of idea while design focus on the implementation view of idea._

A Pattern has four elements:

• Pattern name -It’s a handle we use to describe a problem, solution and it’s consequences. It lets us design at a higher level of abstraction.
• Problem - Problem describes when to apply the pattern, it explains the problem and it’s context. It may include a list of conditions that must be met before it makes sense to apply the pattern.
• Solution - The solution describes the elements [object or class] that make up the design, their relationships, responsibilities, and collaborations. The solution doesn’t describe a particular concrete design, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem.
• Consequences -The consequences are the trade-offs of applying the pattern. They are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences of a pattern include its impact on a system's flexibility, extensibility, or portability.

Classification:

Design Patterns are divided into 3 categories:

• Creational Patterns
• Structural Patterns
• Behavioral Patterns

Creational Patterns:

It provide object creation mechanisms that increase flexibility and reuse of existing code.

• Object Pool Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.

• 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.

• Builder Separate the construction of a complex object from its representation. Read More…

• Singleton Ensure a class has only single instance. Read More…

• Prototype A fully initialised instance to be copied or cloned. Read More…

Structural Patterns:

Explain how to assemble objects and classes into larger structures while keeping the structures flexible and efficient.

• Adapter Convert the protocol of a class into another protocol consumer expect.

• Bridge Decouple an abstraction from its implementation

• Composite A tree structure of simple and composite objects

• Decorator Attach additional responsibilities to an object dynamically

• Facade A single class that represents an entire subsystem

• _Flyweight A fine-grained instance used for efficient sharing

• Proxy An object representing another object

Behavioral Patterns:

Take care of effective communication.

The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.

• Chain of Responsibility OR Responder Chain: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. In Swift it’s called Responder Chain

• Command Encapsulate a command request as an object

• Interpreter A way to include language elements in a program

• Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

• Mediator Define an object that encapsulates how a set of objects interact.

• Memento Capture and restore an object’s internal state

• Observer A way of notifying change to a number of classes

• State Alter an object to alter it’s behaviour when its state changes

Key Takeaways:

Design pattern may just be a sign that some features are missing in a particular programming language. 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are eliminated (via direct language support) in Lisp - Refer https://en.wikipedia.org/wiki/Lisp_(programming_language)

I would write an article on each design pattern, then based on the language you can determine which functionality is already available and which one not. Source code will be in Swift but anyone could grasp the context of design pattern.

Design Patterns Relationships:

References:

Software design pattern