Design Patterns Simplified - Part 3 (Simple Factory)

I am here to continue the discussion of Design Patterns. Today we will explain another creational design pattern called Simple Factory.

In case you have not had a look at our previous articles, go through the following link:

• Design Patterns Simplified: Part 1
• Design Patterns Simplified: Part 2 (Singleton)

Before talking about its implementation let's begin with some fundamental questions as in the following.

Purpose of the Factory pattern

I can think of two main objectives of using the Factory pattern. One is to achieve loose coupling between the client and business layer, another is to keep all the code for all the object instantiation logic in one place.

Purpose of loose coupling

In modern software development where changes in existing systems are frequent and software design is expected to be scalable, not having a loosely-coupled design can create many problems.

For example, in an application with a 3-layer architecture, if object creation logic is at the client side, for any new addition of concrete classes, the developer needs to modify not just the business but the client layer as well. Think about the maintainability and added testing effort.

How about if the client is only aware of the high-level contracts and not about its concreate implementation?

Yes, you got it right! The client just must pass the type of the object it needs and it will get it using the Factory Pattern.

Enough theory. Now let's talk about implementation.

How to use the Simple Factory Pattern

Let's try to understand using a simple example.

Assume the client wants to know the on-road price of various brands of cars and have an interface as in the following.

We need to create a Factory class now that will sit between the client and business layers and it will provide the required object to the client based on the car brand passed.

And here goes the concreate business classes.

Now let's see how the client can use the setup we have created so far.

Output: