Our endless search for patterns

James Jackson
March 4, 2021

In software engineering, a design pattern is a repeatable solution to a commonly occurring problem in software design. Christopher Alexander, a civil engineer, is the one who came up with the idea of design patterns. While working on designing buildings and towns, he found that there are common design problems and certain design constructs can be used repeatedly to solve them.  He documented and published his experiences on design patterns.

Around three decades ago, software professionals began to incorporate Alexander’s design principles. This early work led others to write on design patterns in software development. In 1995, Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides published their book Design Patterns: Elements of Reusable Object Oriented Software [1]. This book became the most popular book on design patterns. The design patterns in this book are also called as “Gang of Four” (GOF) as there were four authors. These design patterns are still relevant and widely used. GOF design patterns are based on Object Oriented programming and are language agnostic. This blog post describes the purpose of all 23 GOF design patterns.

Along with GOF, there are other design patterns which are also used in software design. There are technology specific design patterns such as Core Java EE design patterns [2]. There are design patterns that solve design problems in a particular type of application such as Workflow patterns [3]. There are concurrency patterns [4] to address design issues in multithreaded applications, Enterprise Integration Patterns [5] that help in designing integrated applications. There are architecture patterns that help us in designing robust enterprise applications [6]. There are also design patterns for SOAP and RESTful web services [7].

The design patterns also provide a vocabulary for communication and documentation of software designs.

Object Oriented Programming and Domain Modeling

Object oriented programming has helped in making code more maintainable with features such as encapsulation and inheritance as compared to procedural programming. A class defines attributes and behavior related to an entity, thus providing encapsulation or a boundary. Objects enable domain modeling.

A domain is a collection of objects and their relationships. If entities of an application are designed using domain modelling [7], they enable to define entities and their relationships. The domain models can be used to document complex domains.

Java Persistance API (JPA), a Java technology that maps objects to relational database and provides abstraction over the JDBC, uses domain modeling to define entities and their relationships.


SOLID design principles by Robert Martin are the object oriented principles that help to write easily readable and maintainable code. SOLID is an acronym that stands for S – Single Responsibility principle, O – Open Closed principle, L – Liskov Substitution principle, I – Interface Segregation principle and D – Dependency Injection.

Single Responsibility principle

This design principle (S in SOLID) states that a class should have only one reason to change.  A class should have only one responsibility and there should be one class for one responsibility. Classes that adhere to this principle have high cohesion and are more maintainable then classes that don’t support this principle.

For example, if you have to parse different message formats then create a separate class for parsing each format instead of writing code in a single class. If a message format changes, then only the respective class will change. Classes for other formats will not change and they don’t need to be tested.

Composite design pattern which is a GOF design pattern uses Single Responsibility design principle.

Open Closed principle

The Open Closed design principle (the O in SOLID) states that a class should be open for extension but closed for modification. This principle restricts addition of new behavior in existing class hierarchy but allows extending the hierarchy by addition of subclasses. The Decorator and Strategy GOF design patterns follow Open Closed design principle. Decorator allows extension of behavior during runtime whereas Strategy allows implementation of behavior during compile time.

Dependency Inversion principle/Dependency Injection/The Hollywood principle

Dependency Inversion principle states that instead of instantiating referenced classes within a class, they should be instantiated outside the class definition and passed as references in the class. Dependency Inversion (D in SOLID) injects the reference of the class instance through setter methods of interface or abstract class type. Dependency Inversion relies on abstraction instead of concrete classes. This design principle promotes loose coupling. Since the objects are instantiated outside the class and not within the class this is also called as Inversion of Control.

As Dependency Inversion relies on abstraction, any concrete class instance of the abstract class type can be used. Since the objects are instantiated outside the referenced classes, changes from one object to another of same abstract class type can be done easily without changing the referenced classes. Also, this code change is done at one place instead of making change in every referenced class. This is the advantage of using Dependency Inversion.

The terms Inversion of Control, Dependency Injection, Dependency Inversion mean the same. The term Hollywood principle (don’t call us, we’ll call you) also means the same.

Spring framework provides Dependency Injection.

EJB 3.1 uses both Context and Dependency Injection.

The Factory Method, Template Method, Observer and Chain of Responsibility GOF design patterns follow Dependency Inversion principle.

Written by
James Jackson
Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae.