SOLID Principles in TypeScript

TypeScript had a tremendous impact on the matter of writing clean code in JavaScript. But there are always ways to improve, and one significant way to write better and cleaner code is to follow the so-called SOLID design principles invented by Robert C. Martin (also known as Uncle Bob).

In this article, I will be introducing you to these principles with examples written in TypeScript. I’ve deployed all examples on this Github repository.

Photo by Safar Safarov on Unsplash

Single Responsibility Principle (SRP)

“There should never be more than one reason for a class to change.”

A class should have one purpose/responsibility and therefore only one reason to change. Following this principle leads to better maintenance of the code and minimizes potential side effects.

In the following bad example, you see how there are multiple responsibilities. First, we model a book, but also, we save the book as a file. We ran into 2 purposes here:

bad way

The second example shows you how to deal with this by following the Single Responsibility Principle. Instead of having only one class, we end up having two classes. One for each purpose.

good way

Open-Close Principle (OCP)

“Software entities … should be open for extension, but closed for modification.”

Instead of overriding your class, better extend it. It should be easy to extend the code by new features w/o touching the old code. For instance, implementing an interface or class is very helpful here.

In the next example, you’ll see the wrong way of doing it. We used a third class called AreaCalculator to calculate the area of the Rectangle and Circle classes. Imagine we would add later another shape, which means, we need to create a new class, in that case, we would also need to modify the AreaCalculator class in order to calculate the area of the new class. That’s against the Open-Close Principle.

Let’s have a look:

bad way

So, what can we do to improve this code? In order to follow the Open-Close Principle, we simply add an interface called Shape, so every shape class (Rectangle, Circle, etc.) can depend on this interface by implementing it. In this way, we can simplify the AreaCalculator class to just one function which takes an argument, and this argument is based on the interface we just created.

good way

Liskov Substitution Principle (LSP)

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Lower classes that use pointers or references to upper classes must be able to use objects of derived classes without knowing it. These lower classes should just extend the upper class, not change it.

So what do we see in our next bad example? We got two classes. The Square class extends the Rectangle class. But as we can see, this extension doesn’t make any sense, because we changed the logic by kinda overwriting the properties width and height.

bad way

So instead of overwriting we simply remove the Square class and bring its logic to the Rectangle class w/o changing its purpose.

good way

Interface Segregation Principle

“Many client-specific interfaces are better than one general-purpose interface.”

Simply said, more interfaces are better than having too few. Let me explain the next bad example.

We have a class called Troll which implements an interface called Character. But since our troll can neither swim nor talk, this Character interface doesn’t seem to be the right fit for our class.

bad way

So what can we do about it by following this specific principle? We remove the Character interface and split its features into four interfaces instead and depend our Troll class only on these interfaces which we actually need.

good way

Dependency Inversion Principle (DIP)

“Depend upon abstractions, [not] concretions.”

What the hell that does mean, right? Well, actually it’s pretty simple. Let’s demystify it!

In this bad example, we have a SoftwareProject class, which initializes the FrontendDeveloper and BackendDeveloper classes. But this is the wrong way since these two classes are very similar to each other, I mean, they shall do similar things. So there is a better way to fulfill the requirements in order to achieve the goal of the Dependency Inversion Principle.

bad way

So what are we going to do about it? As I said, it’s actually pretty simple and it’s even easier since we have learned all other principles before.

First of all, we create an interface called Developer, since FrontendDeveloper and BackendDeveloper are similar classes, we depend them on the Developer interface.

Instead of initializing FrontendDeveloper and BackendDeveloper in a single way inside the SoftwareProject class, we take them as a list to iterate through them in order to call each develop() method.

good way

Thank you for reading my first article on Medium. I hope I have been able to refresh your knowledge. You can read more about SOLID on Wikipedia. Thanks to Programmieren Starten, a YouTube channel where my coding examples are based on.

Unlock 10x development with independent components

Building monolithic apps means all your code is internal and is not useful anywhere else. It just serves this one project. And as you scale to more code and people, development becomes slow and painful as everyone works in one codebase and on the same version.

But what if you build independent components first, and then use them to build any number of projects? You could accelerate and scale modern development 10x.

OSS Tools like Bit offer a powerful developer experience for building independent components and composing modular applications. Many teams start by building their Design Systems or Micro Frontends, through independent components. Give it a try →