Design Patterns: Creational Patterns – Series 1/3

0
Article Image

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.

Abstract Factory Pattern

 

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.

Written by Prashant Thomas

Fiscally conscious & goal driven professional with over 15 years of strategic IT experience in multiple disciplines. He has completed his Engineering & M.S. in the US and followed it up with very strong IT leadership experience with top companies. He has a rich cross functional experience in translating business needs into technology requirements, defining, developing roadmaps, rolling out IT solutions across the segments of enterprise. He is a certified Scrum Master and a TOGAF Certified Enterprise Architect.

  • Facebook
  • Twitter
  • Linkedin
  • Google Plus

Interested in Verbat's Services, click below:

Quick Enquiry

Join the conversation

Interested in our services?

We'd love to be your Technology Services Partner.

Click here