Design Patterns: the ignored terrain!

Smit Srivastava
Feb 21 · 7 min read

This article covers what design pattern is and its different categories with one example.

Source: Pexel by Iva Muskic

Recently, I mentioned to someone who is a software developer that I am reading an article on Design Patterns. And the look I got was — What’s that? I checked with few other developers and the responses were more or less similar. To cut the long story short, I came to know that many developers are not aware of the design patterns concept at all or have just heard the terms or confuse them with design principles. Disclaimer: I am talking about developers with experience of less than 3–4 years, and it’s not true for all developers. So, I thought I will write a primer on the design patterns. This article is going to be very basic and we will not dive deep into any of the patterns.

What is a Design Pattern?

Throughout our careers in software engineering, we all have seen similar kinds of design problems occurring again and again. Many times we started with one approach to solving it and then later found out an issue with that approach and then tried another and so on. After few iterations, we finalized an approach that was ideal for the given scenario. We are not the first ones to face this problem neither we are the first ones to solve it. Experts in the industry over the period faced similar kinds of recurring design problems and they developed a standard solution for the same. A design pattern is nothing but a practical proven solution to a recurring design problem. It allows us to use previously outlined solutions that expert developers have often used to solve a software problem so that we do not need to build a solution from the basics of object-oriented programming principles every time. These also help in providing structure to the code and avoid ‘spaghetti code’. It’s important to understand these are not a set of source code that one can memorize and put in their software like a java library or framework. Instead, these are more conceptual. We can take the chess analogy to understand it better. Knowing the rules of chess is like knowing the syntax and elements of a software language for example writing loops, creating classes, etc. As a novice, our main focus remains on the rules of chess and then the next step usually is to think about the next moves. However, if we gain experience in chess or if we observe an expert player, he/she is not thinking these things (these becomes first nature to them) but looking out for specific patterns in the board. There are many known patterns such as the exposed king or the isolated pawns etc. An experienced player will be able to know which patterns to create in what situation of the game and then will be able to exploit the same. It’s the same for the software design patterns too! It’s about knowing the patterns and then recognizing which patterns will fit in the given situations. The first part is the easy one. However, the second part comes with experience. Because there are various design patterns and many times multiple patterns can be applied but not all will be the best one to be used.


Benefits are obvious:

  • No re-inventing the wheel. Experts have already done that we don’t need to go through trials again.

One of the most famous books on design patterns is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. These four are also called the gang of four. When each had developed programs and graphical applications, they had discovered patterns emerging in their design solutions. They formalized those patterns into a reference, which became their book. The patterns developed by the Gang of Four were organized to be readable and often named after their purpose. The grouping of patterns together forms a catalog, otherwise known as the Gang of Four’s design pattern catalog.

Categories of Patterns:

The Gang of Four’s pattern catalog contains twenty-three patterns. These patterns can be sorted into three different categories: creational patterns, structural patterns, and behavioral patterns. This categorization is not hard and fast. Some patterns can span to multiple or all categories.

Creational Patterns: It tackles how we handle creating new objects. It includes both creation and cloning. There are several different patterns based upon creating and cloning objects. For example, if we are creating an object that is similar to an existing one, instead of instantiating a new object, we might clone existing objects. We might choose to clone, rather than instantiate based upon the language we are implementing in. Languages without the notion of classes would encourage us to clone and add to existing objects. Language like Javascript does not contain traditional classes to be instantiated. Objects are instead cloned and expanded to meet the purposes of those particular instances, called prototypes. Javascript allows for changes to these prototypes at run time. Languages like Java and C# on the other hand, rely heavily on instantiating objects using specific classes defined at compile time. The different ways of creating objects can strongly impact how we solve a problem. Different languages, therefore, impact what patterns are possible to use.

Structural Patterns: describes how objects are connected to each other. These patterns relate to the design principles of decomposition and generalization. There are many different ways one can structure objects depending on the relationship one would like between them. Not only do structural patterns describe how different objects have relationships, but also how subclasses and classes interact through inheritance. Structural Patterns use these relationships and describe how they should work to achieve a particular design goal.

Behavioral patterns: focus on how objects distribute work and describe how each object does a single cohesive function. Behavioral patterns also focus on how independent objects work towards a common goal. In a formula-1 race, pit crew at the track is something very similar to this. Each member has a role to perform — changing the tire, un-mounting, mounting bolts, etc. but together they have one goal.

Singleton Design Pattern:

We will take one simple design pattern and will discuss it briefly. We will cover it in detail in the next article. Here the idea is to just give an understanding of a design pattern.

We will take Singleton Pattern. It’s a creational pattern. The Singleton pattern refers to having only one object of a class.

  • In some cases having multiple objects of a class can cause conflicts. In such cases, we go for the singleton pattern.

If we are working alone or on a small project, we can make a comment or mental note — we are not supposed to create multiple objects of the xyz class. But more often than less, we all will be working on a project where multiple developers will be working. Also, one can leave the company and the new person has no clue about it. So, it’s better to codify this design intent in the software itself. We will go over the actual Java code in the next article. However, just to have a better understanding we will briefly discuss how to do the same. If we create a ‘Private’ constructor in the class will it solve the problem? It does solve the problem that it can’t be called from outside the class. But this will also prevent creating an object of the class. To solve this we will do two things -

  • first, we will declare the ‘Private’ class variable. This class variable will refer to the one instance of our Singleton class. As the variable is private, it can only be modified within the class.

As the method is public it can be called globally and can be used to create one instance of the class. The regular constructor is hidden. Other classes will call the public method. This puts the basic gatekeeping and ensures only one object is created. The same method can be used globally to refer to the object if it’s already created. One advantage of this is Lazy creation. That means an object is not created until it is needed. It has its trade-off but here we just wanted to discuss what it is.

I hope this article was able to give some idea about the concept of design patterns. It’s a vast area and requires lots of practical knowledge to get command of it.

Analytics Vidhya

Analytics Vidhya is a community of Analytics and Data…

Sign up for Analytics Vidhya News Bytes

By Analytics Vidhya

Latest news from Analytics Vidhya on our Hackathons and some of our best articles! Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Analytics Vidhya

Analytics Vidhya is a community of Analytics and Data Science professionals. We are building the next-gen data science ecosystem

Smit Srivastava

Written by

IE MBA Graduate| Technical Program/Product Manager [Data Science, Web Development & DevOps]in the Ad-Tech domain| Writer at Analytics Vidhya| A knowledge seeker

Analytics Vidhya

Analytics Vidhya is a community of Analytics and Data Science professionals. We are building the next-gen data science ecosystem

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store