Design Patterns

When working with medium or large projects, it becomes really important that we design our code well. By code design, we mean the way our code is spread across files or classes. Often, companies even have a person whose role is to make design related decisions. This person is called a software architect, and this is another career option that you can consider if you’re interested in computer science.

In this article, I’m not going to go in detail about design patterns. However, my objective is to explain what design patterns are, why they are important, and how you can read about them. So let’s dive right in, and take a look at this part by part.

What are Design Patterns

In Object Oriented Programming, there are specific templates that have been designed. Each template gives us a certain architecture according to which we can write code across different files. For example, one pattern might say that a class should delegate the creation of object to a different class itself, while another might say that a class should keep an object of that type, and make copies of it. You would probably understand this better when we take a look at some examples.

Why Design Patterns

Design patterns are important for multiple reasons. The biggest reason why design patterns came into existence is because code needed to be made reusable. This means that once we have written a code for some class, we should be able to use the class in different scenarios without having to change the code in it. Once again, you would be able to understand this better when we look at some examples.

By making our code reusable, we make our code more maintainable. Not just that, by using existing templates (design patterns), we make our code easier to read. For example, as a new member of a team working on a large project, I would find it much easier to find some code if I knew what file to look for that code in.

Examples

So let’s look at a simple example of a design pattern. The design pattern we are going to look at belongs to a class of patterns called “Creational Design Patterns”, and we are going to look at an example related to game development.

Abstract Factory

Let’s say we want to create a car racing game. To create our car objects, we would normally call the car constructor from our class that handles the race itself. We shall call this the Client class. Hence, we could have something like this:

// Client class
public class Client {

    public startGame() {
        Car c1 = new Car();
        Car c2 = new Car();
        // and so on
    }
}

However, there’s a disadvantage in doing it this way. The problem is, let’s just say we later want to extend our game to boat racing, or airplane racing. I would have to change every car to a boat/airplane from my Client class. So here’s one way to improve things.

We create an abstract Vehicle class, and my car, boat, airplane, all classes inherit this Vehicle class. Next, I can do something like this:

// Client class
public class Client {

    public startGame() {
        Vehicle v1 = new Car();
        Vehicle v2 = new Car();
        // and so on
    }
}

However, to make a transition from a car racing game to a boat racing game, we would still have to make changes to our Client class. In this scenario, we say that the Client class is tightly coupled with the Car class, since it directly uses the Car class constructor in its code. Hence, we look for a way to way to loosen this coupling.

This is where the abstract factory pattern comes in. What abstract factory says is that we should create a class called Vehicle Factory. This class is an abstract class responsible for creation of a vehicle. Next, we add an abstract method createVehicle(), which every vehicle factory must implement.

Next, we create a Car Factory class, which implements this createVehicle method, and returns a Car object. From our client class, we simple call the createVehicle method of a factory.

Here is the code for you to understand this better:

// Client class
public class Client {
    VehicleFactory vehicleFactory;

    Client(VehicleFactory vehicleFactory) {
        this.vehicleFactory = vehicleFactory;
    }

    public startGame() {
        Vehicle v1 = vehicleFactory.createVehicle();
        Vehicle v2 = vehicleFactory.createVehicle();
    }
}
// VehicleFactory class
public abstract class VehicleFactory {
     abstract public Vehicle createVehicle();
}
// CarFactory class
public class CarFactory extends VehicleFactory {
    public Vehicle createVehicle() {
        return new Car();
    }
}

Here is how this design pattern helps. We no longer have to change our Client class to switch to a boat racing game. We can simply make changes to our factory, and we have made a boat racing game. Better still, we can leave our CarFactory as it is, and create a new class, BoatFactory, which again extends the VehicleFactory class. We can then pass this BoatFactory to our Client class via its constructor, and the game would automatically contain boats instead of cars.

Hope you were able to understand design patterns to some extent through this article! There are several more design patterns, and quite a few variations of this very design pattern (and other design patterns) as well.

To sum up, I would just like to mention a resource which you can refer to in case you want to read more about design patterns. It is a book, titled “Design Patterns: Elements of Reusable Object Oriented Software”, written by four authors. Because of it’s long name and multiple authors, it is more popularly known as “Design Patterns by Gang of Four (GoF)”. The book consists of a catalog of 24 design patterns, and explains them in an excellent manner via examples as well as UML diagrams. Do take a look at this book if you’re interested in learning more about design patterns.

I’m also thinking about doing a YouTube series explaining design patterns, so let me know in the comments if you think that would be helpful, or maybe a series of articles with each article explaining a design pattern. Don’t forget to drop a like for this article if you found it interesting and insightful!

Have something to say about this post? Drop a comment here!