DEV Community: Caleb Mantey

Solid Design Principles In Javascript (Part 3) — Interface Segregation Principle & Dependency Inversion

Caleb Mantey — Fri, 11 Feb 2022 12:25:16 +0000

Good design is obvious. Great design is transparent.

Welcome back folks, hope you have been enjoying this series so far. This is the final part of the series. In the previous article we looked at the second and third solid design principle (Open Closed Principle and the Liskov Substitution Principle). In this article we focus on the last two principles which are the Interface Segregation Principle and Dependency Inversion.

If you haven’t read part 1 or part 2 of this article, you can access it here.

You can also access the full code example on my GitHub
https://github.com/Caleb-Mantey/solid-design-principles-in-js
Now lets recap what our code looks like from (part 1 & 2)

Mailer

class Mailer{
        constructor(mail, mailerFormats){
            this.mail = mail
            this.mailerFormats = mailerFormats
            this.smtpService = new PostMarkSmtpService()
            // OR this.smtpService = new SendGridSmtpService()
        }    

        send(){
            // Loops through mail formats and calls the send method
            this.mailerFormats.forEach((formatter) => 
            this.smtpService.send(formatter.format(this.mail)))
        }
}

MailerSmtpService

class MailerSmtpService{
        constructor(smtp_connection = () => {
            //connects to default smtp service
        }){
           this.smtp_con = smtp_connection()
        }   

        send (mail){
            this.smtp_con.send(mail)
        }
}

PostMarkSmtpService

class PostMarkSmtpService extends MailerSmtpService {
        constructor(){
           super(() => {
                // Connects to postmark smtp service
            })
        }    

        send (mail){
            this.smtp_con.send(mail)
        }
}

SendGridSmtpService

class SendGridSmtpService extends MailerSmtpService {
        constructor(){
            super(() => {
                // Connects to sendgrid smtp service
            })
        }      

        send (mail){
            this.smtp_con.deliver(mail)
        }
}

HtmlFormatter

class HtmlFormatter{
        constructor(){
        }        

        format(mail){
             // formats to html version of mail
             mail = `<html>
            <head><title>Email For You</title></head>
            <body>${mail}</body>
            </html>`;            
            return mail;
        }
}

TextFormatter

class TextFormatter{
        constructor(){
        }   

        format(mail){
             // formats to text version of mail
             mail = "Email For You \n" + mail;          
             return mail;
        }
}

The code above is doing the following.

A base class that sets up the behaviour of an smtp service (MailerSmtpService)
A child class that inherits from MailerSmtpService class and connects to an smtp service (PostMarkSmtpService)
A child class that inherits from MailerSmtpService class and connects to an smtp service (SendGridSmtpService)
A class that formats our mail in text (TextFormatter)
A class that formats our mail in html (HtmlFormatter)
A class responsible for sending the mail (Mailer)

This code is tied together in our Mailer class when it is instantiated and can be used to send an email like this.

const mailer = new Mailer(“hello kwame”, [new HtmlFormatter(), new TextFormatter()])
mailer.send();

This is the implementation we had from part 1 and 2 of this article. To follow along i recommend you read part 1 and 2 if you haven’t read it. You can do so by visiting the links provided at the beginning of this text.

Interface Segregation Principle

This principle states that

Do not force any client to implement an interface which is irrelevant to them.

This principle is similar to the single responsibility principle but applies to interfaces. It is usually referred to as the first principle of interfaces. Since javascript does not support interfaces we will implement it with typescript to get a better understanding. Let’s take our first example where we had the HtmlFormatter and TextFormatter class which formats our email and do some few changes.

IFormatter

export interface IFormatter {
        format(mail: string): string
        custom_styles(): string
}

HtmlFormatter

class HtmlFormatter implements IFormatter {

       format(mail: string) {
            // sends html version of mail
            mail = `<html>
            <head>
            <title>Email For You</title>
            ${this.custom_styles()}
            </head>
            <body>${mail}</body>
            </html>`;
            return mail;
        }

        custom_styles(): string {
            return "<style>body{background-color: blue}</style>"
        }
}

TextFormatter

class TextFormatter implements IFormatter {

        format(mail: string) {
            // sends text version of mail
            mail = "Text Version \n" + mail;
            return mail;
        }

        custom_styles(): string {
            return ""
        }
}

Now with typescript included, we have to declare the return types for our functions and the data type for our variables. We also have the ability to create an interface like we do in languages like c# and java.

With this features available to us, we have added an interface (IFormatter) that exposes two functions (format and custom_styles). Our TextFormatter and HtmlFormatter class are also implementing this interface’s (IFormatter) methods. This will make sure we have the format and custom_styles methods been implemented in both our TextFormatter and HtmlFormatter class. If the format and custom_styles methods are not present in any class that implements the IFormatter interface, our application will throw an error. But, there is a problem here because the custom_styles method is only needed in the HtmlFormatter class to help in styling the html document. However since both the TextFormatter and HtmlFormatter class are using the same interface (IFormatter) they both have to implement the same methods(custom_styles and format) forcing as to write an empty custom_styles method for the TextFormatter class.

Now lets see a better approach:

IStyles

export interface IStyles {
        custom_styles(): string
}

IFormatter

export interface IFormatter {
        format(mail: string): string
}

HtmlFormatter

class HtmlFormatter implements IFormatter, IStyles {
       format(mail: string) {
            // sends html version of mail
            mail = `<html>
            <head>
            <title>Email For You</title>
            ${this.custom_styles()}
            </head>
            <body>${mail}</body>
            </html>`;
            return mail;
        }

        custom_styles(): string {
            return "<style>body{background-color: blue}</style>"
        }
}

TextFormatter

class TextFormatter implements IFormatter {
        format(mail: string) {
            // sends text version of mail
            mail = "Text Version \n" + mail;
            return mail;
        }
}

Now you can see from the code refactor we have a new interface IStyles as well as our previous interface IFormatter. Also the HtmlFormatter class implements both the IStyles and IFormatter interface whiles the TextFormatter class implements only the IFormatter interface. This now makes our code cleaner and ensures the right methods are been implement in the classes that needs them. Now our TextFormatter class does not need to implement the custom_styles method since we have removed the custom_styles method from the IFormatter interface to a new interface (IStyles). This makes our code more maintainable and scalable. This is the Interface Segregation Principle at work.

Dependency Inversion Principle

This principle is divided into two parts and it states that

High-level modules/classes should not depend on low-level modules/classes. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

The above lines simply state that if a high level module or class will be dependent more on a low-level module or class, then your code would have tight coupling and if you try to make a change in one class it can break another class. It is always better to abstract the code to make classes loosely coupled as much as you can. This makes maintaining the code easy.

There’s a common misunderstanding that dependency inversion is simply another way to say dependency injection. However, the two are not the same.

In our previous example we created two new interfaces IStyles and IFormatter which where implemented in the TextFormatter and HtmlFormatter class.
Now lets see how these classes can be used with abstraction in the example below:

Mailer

class Mailer {
    mail: string;
    mailerFormats: Array<IFormatter>; // abstraction
    smtpService: MailerSmtpService;

    constructor(mail: string, mailerFormats: Array<IFormatter>/*abstraction*/) {
        this.mail = mail;
        this.mailerFormats = mailerFormats;
        this.smtpService = new SendGridSmtpService();
    }

    send() {
        // Loops through mail formats and calls the send method
        this.mailerFormats.forEach((formatter) =>
        this.smtpService.send(formatter.format(this.mail))
        );
    }
}

Now lets look at the refactor of the Mailer class from our first example (the first principle - Single responsibility principle). You can see we now have a mailerFormats property which takes an array of IFormatter objects (mailerFormats: Array<IFormatter>;). This means any class that implements the IFormatter interface can be stored in this array. Also our Mailer class doesn't need to know about what formatter we are going to use. All it cares about is the formatter is implementing an IFormatter interface and it has a format method which we can call when the need arises. This will allow our Mailer class to be loosely coupled with our HtmlFormatter and TextFormatter class.
Our Mailer class is now depending an abstraction(IFormatter) of the HtmlFormatter and TextFormatter class.

Thanks for your time. This brings us to the end of this series. If you find my content interesting and want to learn more please like and give me a follow.

I will be posting a lot of articles on different topics in the coming weeks, so if you don’t want to miss out then keep your eye on this space to stay updated.

You can also follow me on my github.
https://github.com/Caleb-Mantey/

Solid Design Principles In Javascript (Part 2) — Open-Closed Principle / Liskov Substitution Principle

Caleb Mantey — Thu, 10 Feb 2022 13:09:44 +0000

Design is beautiful when it is simple

Hello readers, in my previous article i talked about solid design patterns and covered the first principle (Single Responsibility Principle). In this article we focus on the second and third principle which is the Open Closed Principle and the Liskov Substitution Principle.

If you haven’t read part 1 of this article, don’t worry you can read it here.

Part 1

You can also access the full code example on my GitHub
https://github.com/Caleb-Mantey/solid-design-principles-in-js

In our previous article we had some code that looked like this:

Mailer

class Mailer{
        constructor(mail, mailerFormats){
            this.mail = mail
            this.mailerFormats = mailerFormats
            this.smtpService = new MailerSmtpService()
        }         

        send(){
            // Loops through mail formats and calls the send method
            this.mailerFormats.forEach((formatter) => 
            this.smtpService.send(formatter.format(this.mail)))
        }
    }

MailerSmtpService

class MailerSmtpService{
        constructor(){
           this.smtp_con = this.smtp_service_connection()
        } 

        send (mail){
            this.smtp_con.send(mail)
            // can easily change to be this if a service requires    this implementation - smtp_con.deliver(mail)
        }     

         smtp_service_connection(){
            // Connects to smtp service
        }
    }

HtmlFormatter

class HtmlFormatter{
        constructor(){
        }        

        format(mail){
             // formats to html version of mail
             mail = `<html>
            <head><title>Email For You</title></head>
            <body>${mail}</body>
            </html>`;            
            return mail;
        }
    }

TextFormatter

class TextFormatter{
        constructor(){
        }      

        format(mail){
             // formats to text version of mail
             mail = "Email For You \n" + mail;          
             return mail;
        }
    }

Looking at the code above we are not doing anything much, we have just separated the logic for sending emails into separate classes.

The code above is doing the following.

A class that connects to the smtp service (MailerSmtpService)
A class that formats our mail in text (TextFormatter)
A class that formats our mail in html (HtmlFormatter)
A class responsible for sending the mail (Mailer)

From the code above we can simply call the Mailer class and pass some required properties to its constructor method (mail, mailerformats) which will be used to setup our mail.

const mailer = new Mailer(“hello kwame”, [new HtmlFormatter(), new TextFormatter()])
mailer.send();

Now lets see how we can make this code even better with the open-closed principle.

Open-closed Principle

This principle states that a class must be open for extension but close to modification.

This principle focus on the fact that a class must be easily extended without changing the contents of the class. If we follow this principle well we can actually change the behaviour of our class without ever touching any original piece of code. This also means if a Developer named Fred works on a certain feature and another Developer named Kwame wants to add some changes, then Kwame should be able to do that easily by extending on the features Fred has already provided.
Let’s take our MailerSmtpService class in the first example and let’s make it support this principle.

MailerSmtpService — ( Initial Implementation)

This is our initial implementation for the MailerSmtpService. Nothing fancy here yet. All we are doing is connecting to an smtp service in the constructor method and storing the result of the connection in this.smtp_con, then we provide a send method that takes a mail as an argument and sends an email.
But we have a problem here. Let’s say we want to change the smtp service provider. We will have to come to our MailerSmtpService class and implement the new smtp service here. However we can do better and use the open-closed principle to make our code more maintainable and even provide the option for switching smtp service providers without touching any piece of existing code.

class MailerSmtpService{
        constructor(){
           this.smtp_con = this.smtp_service_connection()
        }

        send (mail){
            this.smtp_con.send(mail)
            // can also be this.smtp_con.deliver(mail)
        }

        smtp_service_connection(){
            // Connects to smtp service
        }
}

MailerSmtpService — ( Enhanced Version)

Now in order to support the open-closed principle, we will remove the smtp_service_connection method from our MailerSmtpService class and rather we pass the method as a parameter in the MailerSmtpService constructor, then in a subclass (PostMarkSmtpService and SendGridSmtpService) that inherits from MailerSmtpService we call the constructor method of the base class with super(() => {}) then we pass a method which handles the smtp connection depending on the smtp provider in use. Also we override the send method in the parent class (MailerSmtpService ) and each of the child classes(PostMarkSmtpService and SendGridSmtpService) implement their custom versions of the send method.

class MailerSmtpService{
        constructor(smtp_connection = () => {
            //connects to default smtp service
        }){
           this.smtp_con = smtp_connection()
        }

        send (mail){
            this.smtp_con.send(mail)
        }
}

PostMarkSmtpService

class PostMarkSmtpService extends MailerSmtpService {
        constructor(){
           super(() => {
                // Connects to postmark smtp service
            })
        }

        send (mail){
            this.smtp_con.send(mail)
        }
}

SendGridSmtpService

class SendGridSmtpService extends MailerSmtpService {
        constructor(){
            super(() => {
                // Connects to sendgrid smtp service
            })
        }

        send (mail){
            this.smtp_con.deliver(mail)
        }
}

In our mailer class we can now create a new PostMarkSmtpService or SendGridSmtpService in our app and we can easily keep extending to support different smtp service by inheriting from the MailerSmtpService class.

class Mailer{
        constructor(mail, mailerFormats){
            this.mail = mail
            this.mailerFormats = mailerFormats
            this.smtpService = new PostMarkSmtpService()
            // OR this.smtpService = new SendGridSmtpService()
        }

        send(){
            // Loops through mail formats and calls the send method
            this.mailerFormats.forEach((formatter) => 
            this.smtpService.send(formatter.format(this.mail)))
        }
}

With this implementation a developer can keep extending the MailerSmtpService to support more mailing services without modifying the existing logic in the MailerSmtpService class.

This is the open-closed principle at work.

Liskov Substitution principle

The next principle is the Liskov substitution principle it is easier to understand this principle because we have already implemented it in our code example above.

This principle states that

Derived or child classes must be substitutable for their base or parent classes.

This means that a parent class should be easily substituted by the child classes without blowing up the application. This principle can be seen in the example above where we created a parent class called MailerSmtpService and we had two child classes called PostMarkSmtpService and SendGridSmtpService. You can observe that the child classes where used as substitute for the parent class with ease.

For example with typescript we can infer the type of PostMarkSmtpService and SendGridSmtpService to be their parent class MailerSmtpService and the application will still work without any errors.

mailerSmtp: MailerSmtpService = new MailerSmtpService();
postmarkMailerSmtp: MailerSmtpService = new PostMarkSmtpService();
sendgridMailerSmtp: MailerSmtpService = new SendGridSmtpService();

Thanks for your time. Give me a follow or a like if you loved this article.
Watch out for the final part (part 3) of this series where we talk about the last two principles (Interface Segregation Principle and Dependency Inversion)

Solid Design Principles In Javascript (Part 1) — Single Responsibility Principle

Caleb Mantey — Thu, 10 Feb 2022 10:52:54 +0000

Hi i am Mantey Caleb a software engineer based in Accra, Ghana. One of the things i have been doing recently is reading about design patterns and practicing a lot. I tried applying some of the principles in some of my personal work and i am impressed by how much my code looks cleaner and maintainable.
But don’t get me wrong, some of these principles should not just be applied to any problem you come across. They are a good skill to have as a developer but you should know when to use them and not just applying them to every problem you encounter.

In this article i will talk about solid design principles with examples in javascript.

SOLID Design Principles

SOLID PRINCIPLE is usually referred to as the first five principles of object oriented design. This principle was formulated by Robert C. Martin (also known as Uncle Bob). In this article i will be using javascript to explain certain concepts. Javascript doesn’t support features like interfaces and abstract classes but with the addition of typescript we can write javascript like we do in other languages like c# and java. So in this article we will be using typescript too.
Solid principles helps in reducing tight coupling between classes in our code. Tight coupling is when a group of classes highly depend on one another. Loose coupling is the opposite of tight coupling and this approach makes our code more reusable, readable, flexible, scalable and maintainable. It is advisable to avoid tight coupling as much as possible and always make your code loosely coupled.

SOLID stands fo

S — Single Responsibility Principle
O — Open-closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle

In this article we will talk about only the single responsibility principle and reserve the rest for another article.
If you want to see a full explanation of all these principles with code examples, you can check it on my GitHub.

View Github Code

Single Responsibility Principle

Single responsibility principle states that

A class should have one and only one responsibility. Which means your class should have only one job or task.

Consider this example, where we have a mailer class that connects to an smtp service, takes an email, processes it and sends the email as either text or html. Now Let’s see what this class has to do to get the job done.

class Mailer{
        constructor(mail){
            this.mail = mail
            this.smtpService = this.smtp_service_connection()
        }
        smtp_service_connection(){
            // Connects to smtp service
        }
        send(){
            this.smtpService.send(this.format_text_mail())
             this.smtpService.send(this.format_html_mail())
        }
        format_text_mail(){
            // formats to text version of mail
            this.mail = "Email For You \n" + this.mail;
            return this.mail;
        }
        format_html_mail(){
            // formats to html version of mail
             this.mail = `<html>
            <head><title>Email For You</title></head>
            <body>${this.mail}</body>
            </html>`;
            return this.mail;
        }
    }
   const mailer = new Mailer("hello kwame");
   mailer.send();

This code does not follow the single responsibility principle.

The mailer class is responsible for doing all the following

Connects to an smtp service
Format the mail in text format
Format the mail in html format
Sending the mail

This will make the Mailer class very difficult to maintain. Let's say for example we want to change the smtp provider we are using, we will have to come into this class and do some changes to the smtp_service_connection method and this can get tricky and messy if the new provider does not implement a send method but a deliver method, we then will have to also come and change this line this.smtpService.send(this.format_html_mail()) in our send method to this.smtpService.deliver(this.format_html_mail()). All these is a result of the fact that our class is not performing only one functionality.

Better Approach

Mailer

class Mailer{
        constructor(mail, mailerFormats){
            this.mail = mail
            this.mailerFormats = mailerFormats
            this.smtpService = new MailerSmtpService()
        }

         send(){
            // Loops through mail formats and calls the send method
            this.mailerFormats.forEach((formatter) => 
           this.smtpService.send(formatter.format(this.mail)))
        }
}

MailerSmtpService

class MailerSmtpService{
        constructor(){
           this.smtp_con = this.smtp_service_connection()
        }

        send (mail){
            this.smtp_con.send(mail)
            // can easily change to be this (smtp_con.deliver(mail))
           // if a service requires this implementation
        }

        smtp_service_connection(){
            // Connects to smtp service
        }
}

HtmlFormatter

class HtmlFormatter{
        constructor(){
        }

        format(mail){
             // formats to html version of mail
              mail = `<html>
            <head><title>Email For You</title></head>
            <body>${mail}</body>
            </html>`;
            return mail;
        }
}

TextFormatter

class TextFormatter{
        constructor(){
        }

        format(mail){
             // formats to text version of mail
             mail = "Email For You \n" + mail;
             return mail;
        }
}

A more better approach is seen above where we divide all the tasks into separate classes.

We will now have the following.

A class that connects to the smtp service (MailerSmtpService)
A class that formats our mail in text (TextFormatter)
A class that formats our mail in html (HtmlFormatter)
A class responsible for sending the mail (Mailer)

You can see now the code looks better and our smtp service can be changed easily in only one class which does not affect the other parts of the mailing systems behaviour. If we use a new smtp service and it implements a deliver method instead of a send method then we only have to change one method (we change this.smtp_con.send(mail) to this.smtp_con.deliver(mail)) in the MailerSmtpService class. This will not affect other parts of our application and our app will still function properly. The Mailer class takes an instance of a MailerSmtpService class and only sends a mail (NOTE: It is performing one and only one job to send mail)

Also our HtmlFormatter and TextFormatter are doing just one thing formatting the mail in the right format.

Now we can send an email by simply doing this

const mailer = new Mailer("hello kwame", [new HtmlFormatter(), new TextFormatter()])
mailer.send();

Thanks for your time. Give me a follow or a like if you loved this article.
In the next article we expand on this example by focusing on the second and third principle (Open-Closed Principle and Liskov Substitution Principle) to make our code even better.