Software design patterns

S

Hello everyone!

I’m going to start a series of articles on design patterns motivated by the standard book on design patterns – Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. This book is commonly known as “Gang of Four” book or in short, the “GoF” book.

First, we will go through the fundamental patterns which you can find in the “Gang of Four” book. Later, we will examine the complex patterns like MVC, MVP, MVVM, etc. which are used in large software projects.

Pre-requisites

  • OOP concepts – The reader must understand the basic OOP concepts and terminology like polymorphism, inheritance, etc.
  • Some OOP language – The design patterns usually apply to all OOP languages like Java, C#, C++, Kotlin, etc. I will provide the code examples in Kotlin, and the reader should be able to take the same concept and write the code in any of the other languages.

What is a software design pattern?

In simple words, a software design pattern is a way of organizing or structuring our code so that it is easy for us to debug the issues and extend the code in the future without breaking the existing functionality. Everyone who has written some software organized their code in some way and hence followed some design pattern which they thought is most suitable for their code. The study of design patterns helps us to understand some common patterns which are found to be useful in many situations.

Just like we save our time by using libraries written by other people in our code, we can save time by using well-known design patterns in our project. Design patterns will not save our time instantly while writing the code but will save a lot of trouble while fixing issues and adding more features to the project.

You mean software architecure?

One important point to note is that the design is different from software architecture. Architecture defines how the different components will talk to each other in a complex system while the scope of design pattern remains to a single component and how the code will be structured within that component.

Strucuture what?

Specifically, we need to structure how we are going to define our interfaces and classes. In UML, we have the class diagram which presents multiple interfaces & classes and the interactions between them. In this series we are going to learn how to design our class diagrams with the aim to make our structure modular and have as minimum dependencies as possible between classes.

SHOW ME SOME CODE!

Let’s see this with an example. There is a simple requirement to create software for an automobile company where it is required to create classes for different cars offered by the company. A simple way to do this is actually to just create the classes like this-

class AmazingCar {
  val maximumSpeed: Float = 100f
  fun showDemo() {
    println("Demo for the Amazing Car!");
  }
}

class BestCar {
  val maximumSpeed: Float = 140f
  fun showDemo() {
    println("Demo for the best car we have!");
  }
}

fun main(args: Array<String>) {
    BestCar().showDemo()
    AmazingCar().showDemo()
}

Another better way would be to create an interface from which all other classes can inherit and hence can share the same fields and override car specific behaviors.

interface Car {
    var maximumSpeed: Float
    fun showDemo()
}

class BestCar: Car {
    override var maximumSpeed: Float = 140f
    override fun showDemo() {
        println("Demo for the best car we have!");
    }
}

class AmazingCar: Car {
    override var maximumSpeed: Float = 100f
    override fun showDemo() {
        println("Demo for the Amazing Car!");
    }
}

fun showDemo(car: Car) {
    car.showDemo()
}

fun main(args: Array<String>) {
    var car: Car = BestCar()
    showDemo(car)

    car = AmazingCar()
    showDemo(car)
}

By doing this, we are sure that if there are more cars we need to add, we will be able to reference them using the same interface. It will make our code less error-prone and easier to manage. This is exactly the concept behind the design patterns – to make our code less error-prone, modular, and easier to manage.

That’s all for this article. Thank you for reading:)

rEFERENCES

Singleton pattern

About the author

Akshay Jain

I am passionate about programming and feel amazing when I see people using the software I have contributed in. I believe it is essential to write high quality code, which is easy to understand and test. I am still a work in progress and decided to document and share some of my learnings with everyone. Apart from that, I like to read books, and so you might find a lot of book reviews on my blog. I am working as a Software Engineer at Oracle since post-graduation from IISc Bangalore, and happily married :)

Add Comment

Akshay Jain

I am passionate about programming and feel amazing when I see people using the software I have contributed in. I believe it is essential to write high quality code, which is easy to understand and test. I am still a work in progress and decided to document and share some of my learnings with everyone. Apart from that, I like to read books, and so you might find a lot of book reviews on my blog. I am working as a Software Engineer at Oracle since post-graduation from IISc Bangalore, and happily married :)

Get in touch