Software engineering is an amalgamation of a number of concepts, designs and other factors. You explore a bit, start to understand things, and then you realize there’s more to it than what you just understood. But for now, let’s stick to exploring one unique component of software engineering – design patterns.

Basically, a design pattern is just a contextual reusable solution to a commonly occurring problem in software design. It can also be a template that explains ways to solve a problem, and applicable in many different situations in real-world application development, particularly in .NET development.

What design patterns can do

In a nutshell, a design pattern:

• Hastens Software Development process by providing tested development paradigms
• Helps prevent issues that are difficult to detect but can cause major problems
• Improves code readability

In addition to this, design patterns can also help enhance flexibility. But when not used wisely, design patterns may degrade application performance while achieving that required flexibility.

Classification of design patterns

They were originally categorized into three:

• Creational patterns
• Structural patterns
• Behavioral patterns

Another classification was introduced later which proposed the idea of applying design patterns at the architecture level of a software. Model-View-Controller (MVC) pattern is an example.

Creational patterns

In this part of the blog series, let’s get into the details of the first category – Creational patterns.

They primarily deal with creating objects that are necessary for a particular scenario. They streamline object creation, thereby reducing the likelihood of certain design problems.

They are further classified into Class-creational patterns and Object-creational patterns. Class-creational patterns, like the name suggests, deals with class instances while the latter deals with object creation.

5 of the most popular creational patterns include:

• Abstract factory pattern
• Factory method pattern
• Builder pattern
• Prototype pattern
• Singleton pattern

Here’s a brief summary of each pattern and the purpose they serve.

Abstract factory pattern

This design patterns provides various ways to capsulize a group of factory objects without specifying their concrete classes. The client software normally creates an abstract factory implementation first, and then uses the generic interface to create concrete objects that are part of the theme without knowing the objects that are created from each factory.

The merit is that the pattern allows interchanging the implementations during runtime. They don’t have to change the code for that either. However, the system can become difficult to debug if the levels of abstraction passes a certain limit.

Factory method pattern

Problems arise when objects are created without specifying their class. A design pattern used in class-based programming, factory method pattern uses factory methods to deal with those problems. For this, the pattern creates objects without using constructors by using a factory method.

The objects will either be implemented by child classes after it’s specified in an interface, or implemented in a base class. They can also be overridden by derived classes if necessary. Its reliance on inheritance is quite clear from the way it works, and it doesn’t require initialization. Like abstract factory pattern, the factory method pattern also enables polymorphism. A good example is ‘javax.xml.parsers’ package, which features a lot of factories.

Builder pattern

To understand Builder pattern, you should know what a telescoping constructor anti-pattern is. When object constructor parameter combinations are increased, the result is a long list of constructors. This is where the telescoping constructor anti-pattern occurs. Builder pattern is meant to find a solution for this, by using a builder. The builder receives each initialization parameters step by step, to return a constructed object. It can also be used for objects that contain flat data (those that can’t be edited easily), and for encapsulating construction and representation codes. The only disadvantage is that the pattern needs a separate ConcreteBuilder for each type of product.

Protoype pattern

When a prototypical instance is used to determine the type of the objects that are to be created, the prototype pattern is used. The objects created can be cloned to generate new objects. The pattern helps avoid subclasses of an object creator, just like an abstract factory pattern.

In order to implement the prototype pattern, an abstract base class is necessary. This base class should specify a pure virtual clone() method. The client calls the clone() method on the prototype instead of invoking a new operator on some class name. Then a factory method with a parameter is called (that which designates the desired derived class) or invoke the clone() method provided by another pattern.

Unlike factory method pattern, the prototype requires initialization but doesn’t require subclassing.

Singleton pattern

This pattern primarily serves the purpose of restricting the instantiation of a class to a single object. Singleton pattern is ideal when only one object is required to harmonize actions across the system. What makes singleton patterns unique is the fact they are used by other patterns like abstract factory, prototype, and builder in their implementation. State objects are also often categorized as singletons.

Singleton patterns are often preferred to global variables as well. This is because they permit lazy allocation and initialization, whereas global variables almost always use up a lot of resources.