SOLID principles are a set of five design principles used in object-oriented programming. Adhering to these principles will help you develop robust software. They will make your code more efficient, readable, and maintainable.

SOLID is an acronym that stands for:

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Single Responsibility Principle

The single responsibilty principle states that every class must have a single, focused responsibility, a single reason to change.

public class Employee{
  public String getDesignation(int employeeID){ // }
  public void updateSalary(int employeeID){ // }
  public void sendMail(){ // }
}

In the above example, the Employee class has a few employee class-specific behaviors like getDesignation & updateSalary.

Additionally, it also has another method named sendMail which deviates from the responsibility of the Employee class.

This behavior is not specific to this class, and having it violates the single responsibility principle. To overcome this, you can move the sendMail method to a separate class.

Here's how:

public class Employee{
  public String getDesignation(int employeeID){ // }
  public void updateSalary(int employeeID){ // }
}

public class NotificationService {
    public void sendMail() { // }
}

Open/Closed Principle

According to the open/closed priniciple, components must be open for extension, but, closed for modification. To understand this principle, let us take an example of a class that calculates the area of a shape.

public class AreaCalculator(){
  public double area(Shape shape){
    double areaOfShape;
    if(shape instanceof Square){
        // calculate the area of Square
    } else if(shape instanceof Circle){
        // calculate the area of Circle
    }
    return areaOfShape;
  }

The problem with the above example is that if there is a new instance of type Shape for which you need to calculate the area in the future, you have to modify the above class by adding another conditional else-if block. You will end up doing this for every new object of the Shape type.

To overcome this, you can create an interface and have each Shape implement this interface. Then, each class can provide its own implementation for calculating the area. This will make your program easily extensible in the future.

interface IAreaCalculator(){
  double area();
}

class Square implements IAreaCalculator{
  @Override
  public double area(){
    System.out.println("Calculating area for Square");
    return 0.0;
   }
}

class Circle implements IAreaCalculator{
  @Override
  public double area(){
    System.out.println("Calculating area for Circle");
    return 0.0;
   }
}

Liskov Substitution Principle

The Liskov substitution principle states that you must be able to replace a superclass object with a subclass object without affecting the correctness of the program.

abstract class Bird{
   abstract void fly();
}

class Eagle extends Bird {
   @Override
   public void fly() { // some implementation }
}

class Ostrich extends Bird {
   @Override
   public void fly() { // dummy implementation }
}

In the above example, the Eagle class and the Ostrich class both extend the Bird class and override the fly() method. However, the Ostrich class is forced to provide a dummy implementation because it cannot fly, and therefore it does not behave the same way if we replace the Bird class object with it.

This violates the Liskov substitution principle. To address this, we can create a separate class for birds that can fly and have the Eagle extend it, while other birds can extend a different class, which will not include any fly behavior.

abstract class FlyingBird{
   abstract void fly();
}

abstract class NonFlyingBird{
   abstract void doSomething();
}

class Eagle extends FlyingBird {
   @Override
   public void fly() { // some implementation }
}

class Ostrich extends NonFlyingBird {
   @Override
   public void doSomething() { // some implementation }
}

Interface Segregation Principle

According to the interface segregation principle, you should build small, focused interfaces that do not force the client to implement behavior they do not need.

A straightforward example would be to have an interface that calculates both the area and volume of a shape.

interface IShapeAreaCalculator(){
  double calculateArea();
  double calculateVolume();
}

class Square implements IShapeAreaCalculator{
  double calculateArea(){ // calculate the area }
  double calculateVolume(){ // dummy implementation }
}

The issue with this is that if a Square shape implements this, then it is forced to implement the calculateVolume() method, which it does not need.

On the other hand, a Cube can implement both. To overcome this, we can segregate the interface and have two separate interfaces: one for calculating the area and another for calculating the volume. This will allow individual shapes to decide what to implement.

interface IAreaCalculator {
    double calculateArea();
}

interface IVolumeCalculator {
    double calculateVolume();
}

class Square implements IAreaCalculator {
    @Override
    public double calculateArea() { // calculate the area }
}

class Cube implements IAreaCalculator, IVolumeCalculator {
    @Override
    public double calculateArea() { // calculate the area }

    @Override
    public double calculateVolume() {// calculate the volume }
}

Dependency Inversion Principle

In the dependency inversion principle, high-level modules should not depend on low-level modules. In other words, you must follow abstraction and ensure loose coupling

public interface Notification {
    void notify();
}

public class EmailNotification implements Notification {
    public void notify() {
        System.out.println("Sending notification via email");
    }
}

public class Employee {
    private EmailNotification emailNotification; 
    public Employee(EmailNotification emailNotification) {
        this.emailNotification = emailNotification;
    }
    public void notifyUser() {
        emailNotification.notify();
    }
}

In the given example, the Employee class depends directly on the EmailNotification class, which is a low-level module. This violates the dependency inversion principle.

public interface Notification{
  public void notify();
}

public class Employee{
  private Notification notification;
  public Employee(Notification notification){
      this.notification = notification;
  }
  public void notifyUser(){
    notification.notify();
  }
 }

 public class EmailNotification implements Notification{
    public void notify(){
        //implement notification via email 
    }
 }

 public static void main(String [] args){
    Notification notification = new EmailNotification();
    Employee employee = new Employee(notification);
    employee.notifyUser();
 }

In the above example, we have ensured loose coupling. Employee is not dependent on any concrete implementation, rather, it depends only on the abstraction (notification interface).

If we need to change the notification mode, we can create a new implementation and pass it to the Employee.

Conclusion

In conclusion, we've covered the essence of SOLID principles through straightforward examples in this article.

These principles form the building blocks for developing applications that are highly extensible and reusable.

Let's connect on LinkedIn

Its introduction has helped to solve problems associated with the age-long monolithic software development approach, overcoming its cons and achieving scalability.

In this article, I hope to dive deep into what microservices entail and highlight its significant use cases. Also, I will dive deep into the SOLID principles and other best practices necessary to build efficient microservices. With that, let's get started.

First of all, what is a microservice?

What is a Microservice?

This is a type of system architecture in which an application gets structured as a confluence of several independent, loosely coupled independent services. This ensures that each aspect of the overall application gets managed individually and still functions irrespective of the current state of other independent services. These independent servers still allow for information sharing over a given network.

It actively mirrors the distributed system model which segregates the various computers on a network and shares resources amongst them. The adoption of this model by big enterprises has been seen to be advantageous as it has greatly reduced server downtime, minimized costs and maintained efficiency.

The microservice system architecture also provides an upper hand to these firms as it rapidly provides scaling opportunities in case of a spike in user visits. The scaling could either be horizontal which involves activating multiple servers to handle user requests or vertical which involves increasing the CPU power of the server to efficiently handle user requests.

Unlike conventional monolithic systems, microservice best practices deviate slightly from the conventional ACID principles designed for related databases. Hence it's important to learn about best practices and principles which serve as a basis for building resilient microservices.

This will take us into the world of the SOLID principles. The solid principles form the general basis of object-oriented programming and design but have been adapted in the context of building resilient microservices. But what does SOLID represent?

• Single Responsibility Principle
• Open-Close Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Let's discuss these in detail.

Single Responsibility Principle

This principle states that each service in the grand microservice architecture is responsible for a single functionality or possesses a single reason to change. This implies that the service in question is solely and wholly built to fulfil a specific application functionality and it is done cohesively.

This feature provides it with the liberty to scale bigger to effectively deliver on that given functionality. This forms the baseline for microservices development as it reduces the interference of several services due to service interdependency which is a side effect of monolithic applications.

Open-Close Principle

This principle was initially applied for object-oriented programming but is now also adapted for microservices development. It entails that services created within the overall microservice architecture are open to extension with additional service functionalities and communication via the services interface but should be closed to code modification.

This principle is necessary as code modification affects service functionality and stability and also serves as a risk for introducing bugs to the existing code which can ultimately cause errors in system function.

To ensure this, features such as code versioning allow for newer versions of an existing service to be created and deployed without affecting the older versions' functionality and maintain the system's efficiency. Also ensuring the implementation of APIs on each service and the concept of dependency inversion (which will be discussed in the subsequent section) helps to achieve this principle.

Liskov Substitution Principle

This principle is named after its originator, Barbara Liskov. It means that services built within complex microservice architecture can and should be easily substituted or replaced with no or minimal side effects to the entire microservice architecture. This feature also enables developers to build modular microservices applications.

It also enables the execution of the dependency inversion principle which will be discussed in subsequent paragraphs. Achieving this principle involves structuring the microservice architecture with the use of interfaces and classes which allows for the reuse and light coupling of services.

Interface Segregation Principle (ISP)

This principle builds on the Liskov substitution principle and it simply advocates for ensuring that interfaces used for each service are specific for the users who interact with them solely. This ensures that the interface delivers the specific function intended by the service created. This would in turn minimize service interdependency among various services and ensure service application autonomy, enabling it to achieve the desired scalability and overall efficiency possible.

This, alongside the Liskov substitution principle, allows for seamless microservice application evolution over a given cycle. To achieve this, it is important to ensure a minimal reliance of the service on external dependencies and also declare explicit and distinct functions for each service.

Dependency Inversion Principle

This principle negates the age-long tradition in which high-level modules and services tend to depend on smaller low-level services to achieve the necessary efficiency and correctly perform their designated function. It now implies that the high-level services/modules should not depend on anything from the low-level services and both should only interact based on the existing abstraction. In our case, this implies that the interfaces already discussed earlier.

This principle, in line with the other principles, permits easy scaling of each service or module in question and also allows for service reuse or substitution whenever such is needed. This principle has also revolutionized the way applications get built as they now delineate the functions and autonomy of each service in the application.

Additional Information

So far, we have shed light on the SOLID microservices design principles. However, other additional tips which could be of great help when building microservices include:

Availability Over Consistency Principle

This principle is based on the CAP theorem (consistency, availability and partition tolerance. Hypothetically, a system should have all these components implemented and fully functional but in reality, this isn’t so. Ensuring these works often results in network lags, which affects system efficiency, resulting in the need for tradeoffs among these components.

In the case of microservices development, the need for a service to be continually consistent in providing an updated response to a request gets overridden by the need for the service to be available with minimal downtime. Eventually, the overall microservice consistency is achieved during a given period via conflict resolution techniques and other consensus protocols.

Easy Deployability Principle

Unlike conventional monolithic applications, deploying microservices is a bit complex as it requires ensuring seamless communication across various deployments. However, this can be achieved by mastery of some techniques.

Firstly, it's important to possess knowledge of containerization and containerization tools such as Docker. Additionally, knowledge of orchestration tools like Kubernetes is an additional advantage. Adequate knowledge of Infrastructure as Code tools such as Terraform also helps as it gives the developers great control over the application and allows for easy versioning. Provision of monitoring and observability tools to help detect any anomaly in the operations.

Conclusion

With this, we have come to the end of the tutorial. We hope you’ve learned essentially about the principles and other best practices to have in mind when building microservices and other distributed applications.

Feel free to drop comments and questions in the box below, and also check out my other articles here. Till next time, keep on coding!

They were introduced by Robert C. Martin in his 2000 paper “Design Principles and Design Patterns” to help developers write software that is easy to understand, modify, and extend.

These concepts were later built upon by Michael Feathers, who introduced us to the SOLID acronym.

The SOLID acronym stands for:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

These principles provide a way for developers to organize their code and create software that is flexible, easy to change, and testable. Applying SOLID principles can lead to code that is more modular, maintainable, and extensible, and it can make it easier for developers to work collaboratively on a codebase.

In this tutorial, we will explore each of the SOLID principles in detail, explain why they are important, and provide examples of how you can apply them in practice. By the end of this tutorial, you should have a good understanding of the SOLID principles and how to apply them to your software development projects.

What is the Single Responsibility Principle?

The Single Responsibility Principle (SRP) states that a class should have only one reason to change, or in other words, it should have only one responsibility. This means that a class should have only one job to do, and it should do it well.

If a class has too many responsibilities, it can become hard to understand, maintain, and modify. Changes to one responsibility can inadvertently affect another responsibility, leading to unintended consequences and bugs. By following SRP, we can create code that is more modular, easier to understand, and less prone to errors.

Let's take an example that violates the SRP:

class Marker {
    String name;
    String color;
    int price;

    public Marker(String name, String color, int price) {
        this.name = name;
        this.color = color;
        this.price = price;
    }
}

The above code defines a simple Marker class having three instance variables – name, color and price.

class Invoice {
    private Marker marker;
    private int quantity;

    public Invoice(Marker marker, int quantity) {
        this.marker = marker;
        this.quantity = quantity;
    }

    public int calculateTotal() {
        return marker.price * this.quantity;
    }

    public void printInvoice() {
        // printing implementation
    }

    public void saveToDb() {
        // save to database implementation
    }
}

The above Invoice class violates the SRP because it has multiple responsibilities – it is responsible for calculating the total amount, printing the invoice, and saving the invoice to the database. As a result, if the calculation logic changes, such as the addition of taxes, the calculateTotal() method would require modification. Similarly, if the printing or database-saving implementation changes at any point, the class would need to be changed.

There are several reasons for the class to be modified, which could lead to increased maintenance costs and complexity.

Here's how you can modify the code to follow the SRP:

class Invoice {
    private Marker marker;
    private int quantity;

    public Invoice(Marker marker, int quantity) {
        this.marker = marker;
        this.quantity = quantity;
    }

    public int calculateTotal() {
        return marker.price * this.quantity;
    }
}

class InvoiceDao {
    private Invoice invoice;

    public InvoiceDao(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToDb() {
        // save to database implementation
    }
}

class InvoicePrinter {
    private Invoice invoice;

    public InvoicePrinter(Invoice invoice) {
        this.invoice = invoice;
    }

    public void printInvoice() {
        // printing implementation
    }
}

In this refactored example, we have split the responsibilities of the Invoice class into three separate classes: Invoice, InvoiceDao, and InvoicePrinter.

The Invoice class is responsible only for calculating the total amount, and the printing and saving responsibilities have been delegated to separate classes. This makes the code more modular, easier to understand, and less prone to errors.

What is the Open-Closed Principle?

The Open-Closed Principle (OCP) states that software entities (classes, modules, functions, and so on) should be open for extension but closed for modification. This means that the behavior of a software entity can be extended without modifying its source code.

The OCP is essential because it promotes software extensibility and maintainability. By allowing software entities to be extended without modification, developers can add new functionality without the risk of breaking existing code. This results in code that is easier to maintain, extend, and reuse.

Let's take the previous example again.

class InvoiceDao {
    private Invoice invoice;

    public InvoiceDao(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToDb() {
        // save to database implementation
    }
}

The InvoiceDao class has a single responsibility of saving the invoice to the database. But, suppose there's a new requirement to save the invoice to a file as well. One way to implement this requirement would be to modify the existing InvoiceDao class by adding a saveToFile() method. But this violates the Open-Closed Principle because it modifies the existing code that has already been tested and is live in production.

To follow the OCP, a better solution would be to create an InvoiceDao interface and implement it separately for database and file saving as shown below:

interface InvoiceDao {
    public void save(Invoice invoice);
}

class DatabaseInvoiceDao implements InvoiceDao {
    @Override
    public void save(Invoice invoice) {
        // save to database implementation
    }
}

class FileInvoiceDao implements InvoiceDao {
    @Override
    public void save(Invoice invoice) {
        // save to file implementation
    }
}

This way, if there's a new requirement to save the invoice to another data store, you can implement a new InvoiceDao implementation without modifying the existing code. Now the InvoiceDao interface is open for extension and closed for modification, which follows the OCP.

What is the Liskov Substitution Principle?

The Liskov Substitution Principle (LSP) states that any instance of a derived class should be substitutable for an instance of its base class without affecting the correctness of the program.

In other words, a derived class should behave like its base class in all contexts. In more simple terms, if class A is a subtype of class B, you should be able to replace B with A without breaking the behavior of your program.

The importance of the LSP lies in its ability to ensure that the behavior of a program remains consistent and predictable when substituting objects of different classes. Violating the LSP can lead to unexpected behavior, bugs, and maintainability issues.

Let's take an example.

interface Bike {
    void turnOnEngine();

    void accelerate();
}

In the given example, the interface Bike has two methods, turnOnEngine() and accelerate(). Two classes implement this interface, Motorbike and Bicycle.

class Motorbike implements Bike {

    boolean isEngineOn;
    int speed;

    @Override
    public void turnOnEngine() {
        isEngineOn = true;
    }

    @Override
    public void accelerate() {
        speed += 5;
    }
}

Motorbike correctly implements the turnOnEngine() method, as it sets the isEngineOn boolean to true. It also correctly implements the accelerate() method by increasing the speed by 5.

class Bicycle implements Bike {

    boolean isEngineOn;
    int speed;

    @Override
    public void turnOnEngine() {
        throw new AssertionError("There is no engine!");
    }

    @Override
    public void accelerate() {
        speed += 5;
    }
}

However, the Bicycle class throws an AssertionError in the turnOnEngine() method because it has no engine. This means that an instance of Bicycle cannot be substituted for an instance of Bike without breaking the behavior of the program.

In other words, if the Bicycle class is considered a subtype of the Bike interface, then according to the LSP, any instance of Bike should be replaceable with an instance of Bicycle without altering the correctness of the program.

But in this case, it's not true because Bicycle throws an AssertionError while trying to turn on the engine. Therefore, the code violates the LSP.

What is the Interface Segregation Principle?

The Interface Segregation Principle (ISP) focuses on designing interfaces that are specific to their client's needs. It states that no client should be forced to depend on methods it does not use.

The principle suggests that instead of creating a large interface that covers all the possible methods, it's better to create smaller, more focused interfaces for specific use cases. This approach results in interfaces that are more cohesive and less coupled.

Consider a Vehicle interface as below:

interface Vehicle {
    void startEngine();
    void stopEngine();
    void drive();
    void fly();
}

And then you have a class called Car that implements the Vehicle interface:

class Car implements Vehicle {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }

    @Override
    public void fly() {
        throw new UnsupportedOperationException("This vehicle cannot fly.");
    }
}

In this example, the Vehicle interface has too many methods. The Car class is forced to implement all of them, even though they cannot fly. This violates the ISP because the Vehicle interface is not properly segregated into smaller interfaces based on related functionality.

Let's understand how you can follow the ISP here. Suppose you refactor the Vehicle interface into smaller, more focused interfaces:

interface Drivable {
    void startEngine();
    void stopEngine();
    void drive();
}

interface Flyable {
    void fly();
}

Now, you can have a class called Car that only implements the Drivable interface:

class Car implements Drivable {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }
}

And, thanks to interface segregation, you can have another class called Airplane that implements both the Drivable and Flyable interfaces:

class Airplane implements Drivable, Flyable {

    @Override
    public void startEngine() {
        // implementation
    }

    @Override
    public void stopEngine() {
        // implementation
    }

    @Override
    public void drive() {
        // implementation
    }

    @Override
    public void fly() {
        // implementation
    }
}

In this example, you have properly segregated the Vehicle interface into smaller interfaces based on related functionality. This adheres to the ISP and makes your code more flexible and maintainable.

What is the Dependency Inversion Principle?

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules, but both should depend on abstractions. Abstractions should not depend on details – details should depend on abstractions.

This principle aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend.

For example, consider a scenario where you have a class that needs to use an instance of another class. In the traditional approach, the first class would directly create an instance of the second class, leading to a tight coupling between them. This makes it difficult to change the implementation of the second class or to test the first class independently.

But if you apply the DIP, the first class would depend on an abstraction of the second class instead of the implementation. This would make it possible to easily change the implementation and test the first class independently.

Here is an example that violates the DIP:

class WeatherTracker {
    private String currentConditions;
    private Emailer emailer;

    public WeatherTracker() {
        this.emailer = new Emailer();
    }

    public void setCurrentConditions(String weatherDescription) {
        this.currentConditions = weatherDescription;
        if (weatherDescription == "rainy") {
            emailer.sendEmail("It is rainy");
        }
    }
}

class Emailer {
    public void sendEmail(String message) {
        System.out.println("Email sent: " + message);
    }
}

In this example, the WeatherTracker class directly creates an instance of the Emailer class, making it tightly coupled to the implementation. This makes it difficult to change the implementation of the Emailer class or to test the WeatherTracker class independently.

Here is an example of how to apply the DIP to the above code:

interface Notifier {
    public void alertWeatherConditions(String weatherDescription);
}

class WeatherTracker {
    private String currentConditions;
    private Notifier notifier;

    public WeatherTracker(Notifier notifier) {
        this.notifier = notifier;
    }

    public void setCurrentConditions(String weatherDescription) {
        this.currentConditions = weatherDescription;
        if (weatherDescription == "rainy") {
            notifier.alertWeatherConditions("It is rainy");
        }
    }
}

class Emailer implements Notifier {
    public void alertWeatherConditions(String weatherDescription) {
        System.out.println("Email sent: " + weatherDescription);
    }
}

class SMS implements Notifier {
    public void alertWeatherConditions(String weatherDescription) {
        System.out.println("SMS sent: " + weatherDescription);
    }
}

In this example, we created a Notifier interface that defines the alertWeatherConditions method. The WeatherTracker class now depends on this interface instead of the Emailer class, making it possible to easily change the implementation and test the WeatherTracker class independently.

We also created two implementations of the Notifier interface, Emailer, and SMS, to demonstrate how you can change the implementation of the WeatherTracker class without affecting its behavior.

Conclusion

In this article, you learned about the SOLID principles which are a very important part of general Design Principles.

By applying these principles in your software development projects, you can create code that is easier to maintain, extend, and modify, leading to more robust, flexible, and reusable software. This will also lead to better collaboration among team members, as the code becomes more modular and easier to work with.

For more such tutorials, you can follow my personal blog.

The other 4 SOLID design principles are:

• Single Responsibility Principle (SRP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP).

If you want to learn about all these principles, you can read my tutorial on the SOLID principles here.

In this article, I’ll show you what the open-closed principle (OCP) means, why you should use it, and its implementation in JavaScript.

What We'll Cover

• What is the Open-Closed Principle?
• Why should you use the Open-Closed Principle?
• How to implement the Open-Closed Principle in JavaScript
• Conclusion

What is the Open-Closed Principle?

The open-closed principle states that software entities (classes, modules, functions, and so on) should be open for extension, but closed for modification.

You are probably wondering why that statement sounds like a contradiction. Like why would something be opened and be closed at the same time?

Well, in the land of software development, it’s possible for an item to be opened for extension and be closed for modification. It means you or your team members should be able to add new functionalities to an existing software system without changing the existing code.

The open-closed principle encourages software engineers to focus on what’s necessary when it’s time to add new functionalities.

If you want to add new functionality to your existing code and you have to modify it before you add the new functionality, then you are not following the open-closed principle.

Why Should You Use the Open-Closed Principle?

Here are some reasons why you should be using the open-closed principle:

• You don’t need to re-invent the wheel: as the principle states, the code you and your team are working on is closed for extension. This means if you’re following the open-closed principle, you don’t need to reinvent the wheel (and rebuild everything) when you want to add new features.

• You focus on what is necessary: as the OCP states, your code is closed for modification. It means you can add new features without performing too much editing on the existing code, or none at all. This can help you and your team members focus on what is necessary when it’s time to implement new functionalities.

• You can avoid bugs: since you don’t have to edit the existing code before adding new features, you can avoid introducting unnecessary bugs.

-Your code is more maintainable, testable, and flexible: following the OCP will make your codebase loosely coupled. With this the code is more flexible and maintainable. And if you want, you can unit test each class successfully.

How to Implement the Open-Closed Principle in JavaScript

The first example of the open-closed principle I will show is a class using a switch or multiple if statements. That’s because in code like this, there’s a very real possibility you will modify the class using the switch or if statements. And that violates the open-closed principle in the process.

class Footballer {
  constructor(name, age, role) {
    this.name = name;
    this.age = age;
    this.role = role;
  }

  getFootballerRole() {
    switch (this.role) {
      case 'goalkeeper':
        console.log(`The footballer, ${this.name} is a goalkeeper`);
        break;
      case 'defender':
        console.log(`The footballer, ${this.name} is a defender`);
        break;
      case 'midfielder':
        console.log(`The footballer, ${this.name} is a midfielder`);
        break;
      case 'forward':
        console.log(`The footballer, ${this.name} plays in the forward line`);
        break;
      default:
        throw new Error(`Unsupported animal type: ${this.type}`);
    }
  }
}

const kante = new Footballer('Ngolo Kante', 31, 'midfielder');
const hazard = new Footballer('Eden Hazard', 32, 'forward');

kante.getFootballerRole(); // The footballer, Ngolo Kante is a midfielder
hazard.getFootballerRole(); // The footballer, Eden Hazard plays in the forward line

There are more football roles like winger, defensive midfielder, and more. So, in the code above, what do you think would happen if you had to add another footballer role on the pitch? You would have to modify the switch statement. That violates the open-closed principle because you have to modify the existing code.

To fix the violation, you have to create a separate role class to consume the method that gets the player role from the super class. But it doesn’t end there. You then need to create a different class for each role that extends the class which gets the player role.

This will make more sense in code:

class Footballer {
  constructor(name, age, role) {
    this.name = name;
    this.age = age;
    this.role = role;
  }

  getRole() {
    return this.role.getRole();
  }
}

// PlayerRole class uses the getRole method
class PlayerRole {
  getRole() {}
}

// Sub classes for different roles extend the PlayerRole class
class GoalkeeperRole extends PlayerRole {
  getRole() {
    return 'goalkeeper';
  }
}

class DefenderRole extends PlayerRole {
  getRole() {
    return 'defender';
  }
}

class MidfieldRole extends PlayerRole {
  getRole() {
    return 'midfielder';
  }
}

class ForwardRole extends PlayerRole {
  getRole() {
    return 'forward';
  }
}

// Putting all of them together
const hazard = new Footballer('Hazard', 32, new ForwardRole());
console.log(`${hazard.name} plays in the ${hazard.getRole()} line`); // Hazard plays in the forward line

const kante = new Footballer('Ngolo Kante', 31, new MidfieldRole());
console.log(`${kante.name} is the best ${kante.getRole()} in the world!`); //Ngolo Kante is the best midfielder in the world!

Here’s another example that uses functions instead of JavaScript classes:

function calculatePrice(price, discount) {
  if (discount === '10%') {
    return price * 0.9;
  } else if (discount === '20%') {
    return price * 0.8;
  } else if (discount === '30%') {
    return price * 0.7;
  } else {
    throw new Error('Invalid discount');
  }
}

const discountedPrice = calculatePrice(100, '10%');
console.log(`Your discounted price is ${discountedPrice}`); //  The discount you get is 90

The code above violates the open-closed principle because you have to add another if…else statement if you want to add a new discount.

To fix it, you can extract all your discounts to an object and use it in the function this way:

const discounts = {
  '10%': 0.9,
  '20%': 0.8,
  '30%': 0.7,
};

function calculatePrice(price, discountType) {
  const discount = discounts[discountType];
  if (discount === undefined) {
    throw new Error('Invalid discount');
  }
  return price * discount;
}

const discountedPrice = calculatePrice(100, '30%');
console.log(`Your discounted price is $${discountedPrice}`);

Now if you want to add new discounts, you only need to add to the discount object, not the existing function that calculates the discount.

Conclusion

In this article, you learned about the open-closed principle, its benefits, and how to implement it.

To carry out the implementation, we used JavaScript classes to illustrate how you can get it done with JavaScript object-oriented programming. First I showed how the code violates the principle, and how to refactor it so it doesn't.

Since function is also a software entity, we also looked at how you can implement the open-closed principle with JavaScript functions.

Keep coding!

Each of these five design principles solves a particular problem that might arise while developing the software systems.

In this article, I’ll show you what the SOLID principles entail, what each part of the SOLID acronym means, and how to implement them in your code.

What We'll Cover

• What are SOLID Design Principles?
  • The Single Responsibility Principle (SRP)
  • The Open-Closed Principle (OCP)
  • The Liskov Substitution Principle (LSP)
  • The Interface Segregation Principle (ISP)
  • The Dependency Inversion Principle (DIP)
• Conclusion

What are SOLID Design Principles?

SOLID is an acronym that stands for:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

In the coming sections, we’ll look at what each of those principles means in detail.

The SOLID design principles are a subcategory of many principles introduced by the American computer scientist and instructor, Robert C. Martin (A.K.A Uncle Bob) in a 2000 paper.

Following these principles can result in a very large codebase for a software system. But in the long run, the main aim of the principles is never defeated. That is, helping software developers make changes to their code without causing any major issues.

The Single Responsibility Principle (SRP)

The single responsibility principle states that a class, module, or function should have only one reason to change, meaning it should do one thing.

For example, a class that shows the name of an animal should not be the same class that displays the kind of sound it makes and how it feeds.

Here’s an example in JavaScript:

class Animal {
  constructor(name, feedingType, soundMade) {
    this.name = name;
    this.feedingType = feedingType;
    this.soundMade = soundMade;
  }

  nomenclature() {
    console.log(`The name of the animal is ${this.name}`);
  }

  sound() {
    console.log(`${this.name} ${this.soundMade}s`);
  }

  feeding() {
    console.log(`${this.name} is a ${this.feedingType}`);
  }
}

let elephant = new Animal('Elephant', 'herbivore', 'trumpet');
elephant.nomenclature(); // The name of the animal is Elephant
elephant.sound(); // Elephant trumpets
elephant.feeding(); // Elephant is a herbivore

The code above violates the single responsibility principle because the class that's responsible for printing the name of the animal also shows the sound it makes and its type of feeding.

To fix this, you have to create a separate class for the sound and feeding methods like this:

class Animal {
  constructor(name) {
    this.name = name;
  }

  nomenclature() {
    console.log(`The name of the animal is ${this.name}`);
  }
}

let animal1 = new Animal('Elephant');
animal1.nomenclature(); // The name of the animal is Elephant

// Sound class
class Sound {
  constructor(name, soundMade) {
    this.name = name;
    this.soundMade = soundMade;
  }

  sound() {
    console.log(`${this.name} ${this.soundMade}s`);
  }
}

let animalSound1 = new Sound('Elephant', 'trumpet');
animalSound1.sound(); //Elephant trumpets

// Feeding class
class Feeding {
  constructor(name, feedingType) {
    this.name = name;
    this.feedingType = feedingType;
  }

  feeding() {
    console.log(`${this.name} is a/an ${this.feedingType}`);
  }
}

let animalFeeding1 = new Feeding('Elephant', 'herbivore');
animalFeeding1.feeding(); // Elephant is a/an herbivore

This way, each of the classes is doing only one thing:

• the first one prints the name of the animal
• the second prints the kind of sound it makes
• and the third one prints its kind of feeding.

That’s more code, but better readability and maintainability. A developer who didn’t write the code can come to it and understand what’s going on quicker than having it all in one class.

The Open-Closed Principle (OCP)

The open-closed principle states that classes, modules, and functions should be open for extension but closed for modification.

This principle might seem to contradict itself, but you can still make sense of it in code. It means you should be able to extend the functionality of a class, module, or function by adding more code without modifying the existing code.

Here’s some code that violates the open-closed principle in JavaScript:

class Animal {
  constructor(name, age, type) {
    this.name = name;
    this.age = age;
    this.type = type;
  }

  getSpeed() {
    switch (this.type) {
      case 'cheetah':
        console.log('Cheetah runs up to 130mph ');
        break;
      case 'lion':
        console.log('Lion runs up to 80mph');
        break;
      case 'elephant':
        console.log('Elephant runs up to 40mph');
        break;
      default:
        throw new Error(`Unsupported animal type: ${this.type}`);
    }
  }
}

const animal1 = new Animal('Lion', 4, 'lion');
animal1.getSpeed(); // Lion runs up to 80mph

The code above violates the open-closed principle because if you want to add a new animal type, you have to modify the existing code by adding another case to the switch statement.

Normally, if you’re using a switch statement, then it’s very likely you will violate the open-closed principle.

Here’s how I refactored the code to fix the problem:

class Animal {
  constructor(name, age, speedRate) {
    this.name = name;
    this.age = age;
    this.speedRate = speedRate;
  }

  getSpeed() {
    return this.speedRate.getSpeed();
  }
}

class SpeedRate {
  getSpeed() {}
}

class CheetahSpeedRate extends SpeedRate {
  getSpeed() {
    return 130;
  }
}

class LionSpeedRate extends SpeedRate {
  getSpeed() {
    return 80;
  }
}

class ElephantSpeedRate extends SpeedRate {
  getSpeed() {
    return 40;
  }
}

const cheetah = new Animal('Cheetah', 4, new CheetahSpeedRate());
console.log(`${cheetah.name} runs up to ${cheetah.getSpeed()} mph`); // Cheetah runs up to 130 mph

const lion = new Animal('Lion', 5, new LionSpeedRate());
console.log(`${lion.name} runs up to ${lion.getSpeed()} mph`); // Lion runs up to 80 mph

const elephant = new Animal('Elephant', 10, new ElephantSpeedRate());
console.log(`${elephant.name} runs up to ${elephant.getSpeed()} mph`); // Elephant runs up to 40 mph

This way, if you want to add a new animal type, you can create a new class that extends SpeedRate and pass it to the Animal constructor without modifying the existing code.

For example, I added a new GoatSpeedRate class like this:

class GoatSpeedRate extends SpeedRate {
  getSpeed() {
    return 35;
  }
}

// Goat
const goat = new Animal('Goat', 5, new GoatSpeedRate());
console.log(`${goat.name} runs up to ${goat.getSpeed()} mph`); // Goat runs up to 354 mph

This conforms to the open-closed principle.

The Liskov Substitution Principle (LSP)

The Liskov substitution principle is one of the most important principles to adhere to in object-oriented programming (OOP). It was introduced by the computer scientist Barbara Liskov in 1987 in a paper she co-authored with Jeannette Wing.

The principle states that child classes or subclasses must be substitutable for their parent classes or super classes. In other words, the child class must be able to replace the parent class. This has the advantage of letting you know what to expect from your code.

Here’s an example of a code that does not violate the Liskov substitution principle:

class Animal {
  constructor(name) {
    this.name = name;
  }

  makeSound() {
    console.log(`${this.name} makes a sound`);
  }
}

class Dog extends Animal {
  makeSound() {
    console.log(`${this.name} barks`);
  }
}

class Cat extends Animal {
  makeSound() {
    console.log(`${this.name} meows`);
  }
}

function makeAnimalSound(animal) {
  animal.makeSound();
}

const cheetah = new Animal('Cheetah');
makeAnimalSound(cheetah); // Cheetah makes a sound

const dog = new Dog('Jack');
makeAnimalSound(dog); // Jack barks

const cat = new Cat('Khloe');
makeAnimalSound(cat); // Khloe meows

The Dog and Cat classes can successfully replace the parent Animal class.

On the other hand, let’s look at how the code below does violate the Liskov substitution principle:

class Bird extends Animal {
  fly() {
    console.log(`${this.name} flaps wings`);
  }
}

const parrot = new Bird('Titi the Parrot');
makeAnimalSound(parrot); // Titi the Parrot makes a sound
parrot.fly(); // Titi the Parrot flaps wings

The Bird class violates the Liskov substitution principle because it’s not implementing its own makeSound from the parent Animal class. Instead, it’s inheriting the generic sound.

To fix this, you have to make it use the makeSound method too:

class Bird extends Animal {
  makeSound() {
    console.log(`${this.name} chirps`);
  }

  fly() {
    console.log(`${this.name} flaps wings`);
  }
}

const parrot = new Bird('Titi the Parrot');
makeAnimalSound(parrot); // Titi the Parrot chirps
parrot.fly(); // Titi the Parrot flaps wings

The Interface Segregation Principle (ISP)

The interface segregation principle states that clients should not be forced to implement interfaces or methods they do not use.

More specifically, the ISP suggests that software developers should break down large interfaces into smaller, more specific ones, so that clients only need to depend on the interfaces that are relevant to them. This can make the codebase easier to maintain.

This principle is fairly similar to the single responsibility principle (SRP). But it’s not just about a single interface doing only one thing – it’s about breaking the whole codebase into multiple interfaces or components.

Think about this as the same thing you do while working with frontend frameworks and libraries like React, Svelte, and Vue. You usually break down the codebase into components you only bring in when needed.

This means you create individual components that have functionality specific to them. The component responsible for implementing scroll to the top, for example, will not be the one to switch between light and dark, and so on.

Here’s an example of code that violates the interface segregation principle:

class Animal {
  constructor(name) {
    this.name = name;
  }

  eat() {
    console.log(`${this.name} is eating`);
  }

  swim() {
    console.log(`${this.name} is swimming`);
  }

  fly() {
    console.log(`${this.name} is flying`);
  }
}

class Fish extends Animal {
  fly() {
    console.error("ERROR! Fishes can't fly");
  }
}

class Bird extends Animal {
  swim() {
    console.error("ERROR! Birds can't swim");
  }
}

const bird = new Bird('Titi the Parrot');
bird.swim(); // ERROR! Birds can't swim

const fish = new Fish('Neo the Dolphin');
fish.fly(); // ERROR! Fishes can't fly

The code above violates the interface segregation principle because the Fish class doesn’t need the fly method. A fish cannot fly. Birds can’t swim too, so the Bird class doesn’t need the swim method.

Also, the Bird and Fish classes both extend the Animal class, and that violates the ISP since the Animal class has methods that either class does not need.

The goal is to create interfaces that are tailored to the specific needs of each class/functionality.

This is how I fixed the code to conform to the interface segregation principle:

// Define interfaces for different types of animals

class Swimmer {
  constructor(name) {
    this.name = name;
  }

  swim() {
    console.log(`${this.name} is swimming`);
  }
}

class Flyer {
  constructor(name) {
    this.name = name;
  }

  fly() {
    console.log(`${this.name} is flying`);
  }
}

// Implement interfaces for specific types of animals

class Bird extends Flyer {
  constructor(name) {
    super(name);
  }

  eat() {
    console.log(`${this.name} is eating`);
  }
}

class Fish extends Swimmer {
  constructor(name) {
    super(name);
  }

  eat() {
    console.log(`${this.name} is eating`);
  }
}

// Usage

const bird = new Bird('Titi the Parrot');
bird.fly(); // Titi the Parrot is flying
bird.eat(); // Titi the Parrot is eating

console.log('\n');

const fish = new Fish('Neo the Dolphin');
fish.swim(); // Neo the Dolphin is swimming
fish.eat(); // Neo the Dolphin is eating

In the code above, we have a class specifically for animals that swim and another for animals that fly. The Fish and Bird classes only extend classes with methods specific to their needs.

The Dependency Inversion Principle (DIP)

The dependency inversion principle is about decoupling software modules. That is, making them as separate from one another as possible.

The principle states that high-level modules should not depend on low-level modules. Instead, they should both depend on abstractions. Additionally, abstractions should not depend on details, but details should depend on abstractions.

In simpler terms, this means instead of writing code that relies on specific details of how lower-level code works, you should write code that depends on more general abstractions that can be implemented in different ways.

This makes it easier to change the lower-level code without having to change the higher-level code.

Here’s a code that violates the dependency inversion principle:

class Animal {
  constructor(name) {
    this.name = name;
  }
}

class Dog extends Animal {
  bark() {
    console.log('woof! woof!! woof!!');
  }
}

class Cat extends Animal {
  meow() {
    console.log('meooow!');
  }
}

function printAnimalNames(animals) {
  for (let i = 0; i < animals.length; i++) {
    const animal = animals[i];
    console.log(animal.name);
  }
}

const dog = new Dog('Jack');
const cat = new Cat('Zoey');

const animals = [dog, cat];

printAnimalNames(animals);

The code above violates dependency inversion principle because the printAnimalNames function depends on the concrete implementations of Dog and Cat.

If you wanted to add another animal like an ape, you’d have to modify the printAnimalNames function to handle it.

Here’s how to fix it:

class Animal {
  constructor(name) {
    this.name = name;
  }

  getName() {
    return this.name;
  }
}

class Dog extends Animal {
  bark() {
    console.log('woof! woof!! woof!!!');
  }
}

class Cat extends Animal {
  meow() {
    console.log('meooow!');
  }
}

function printAnimalNames(animals) {
  for (let i = 0; i < animals.length; i++) {
    const animal = animals[i];
    console.log(animal.getName());
  }
}

const dog = new Dog('Jack');
const cat = new Cat('Zoey');

const animals = [dog, cat, ape];

printAnimalNames(animals);

In the code above, I created a getName method inside the Animal class. This provides an abstraction that the printAnimalNames function can depend on. Now, the printAnimalNames function only depends on the Animal class, not the concrete implementations of Dog and Cat.

If you wan to add an Ape class, you can do so without modifying the printAnimalNames function:

class Animal {
  constructor(name) {
    this.name = name;
  }

  getName() {
    return this.name;
  }
}

class Dog extends Animal {
  bark() {
    console.log('woof! woof!! woof!!!');
  }
}

class Cat extends Animal {
  meow() {
    console.log('meooow!');
  }
}

// Add Ape class
class Ape extends Animal {
  meow() {
    console.log('woo! woo! woo!');
  }
}

function printAnimalNames(animals) {
  for (let i = 0; i < animals.length; i++) {
    const animal = animals[i];
    console.log(animal.getName());
  }
}

const dog = new Dog('Jack'); // Jack
const cat = new Cat('Zoey'); // Zoey

// Use the Ape class
const ape = new Ape('King Kong'); // King Kong

const animals = [dog, cat, ape];

printAnimalNames(animals);

Conclusion

In this article, you learned what the SOLID design priniples are. We discussed each principle with an example, and went through ways to implement them in JavaScript.

I hope the article gives you a solid grasp of the SOLID principles. You can see that the SOLID design principles can help you create a software system that is free of bugs, maintainable, flexible, scalable, and reusable.

Thanks for reading.princip

They also make it easy to create readable and testable code that many developers can collaboratively work with anywhere and anytime. And they make you aware of the best way to write code 💪.

SOLID is a mnemonic acronym that stands for the five design principles of Object-Oriented class design. These principles are:

• S - Single-responsibility Principle

• O - Open-closed Principle

• L - Liskov Substitution Principle

• I - Interface Segregation Principle

• D - Dependency Inversion Principle

In this article, you will learn what these principles stand for and how they work using JavaScript examples. The examples should be fine even if you are not fully conversant with JavaScript, because they apply to other programming languages as well.

What is the Single-Responsibility Principle (SRP)?

The Single-responsibility Principle, or SRP, states that a class should only have one reason to change. This means that a class should have only one job and do one thing.

Let’s take a look at a proper example. You’ll always be tempted to put similar classes together – but unfortunately, this goes against the Single-responsibility principle. Why?

The ValidatePerson object below has three methods: two validation methods, (ValidateName() and ValidateAge()), and a Display() method.

class ValidatePerson {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    ValidateName(name) {
        if (name.length > 3) {
            return true;
        } else {
            return false;
        }
    }

    ValidateAge(age) {
        if (age > 18) {
            return true;
        } else {
            return false;
        }
    }

    Display() {
        if (this.ValidateName(this.name) && this.ValidateAge(this.age)) {
            console.log(`Name: ${this.name} and Age: ${this.age}`);
        } else {
            console.log('Invalid');
        }
    }
}

The Display() method goes against the SRP because the goal is that a class should have only one job and do one thing. The ValidatePerson class does two jobs – it validates the person’s name and age and then displays some information.

The way to avoid this problem is to separate code that supports different actions and jobs so that each class only performs one job and has one reason to change.

This means that the ValidatePerson class will only be responsible for validating a user, as seen below:

class ValidatePerson {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    ValidateName(name) {
        if (name.length > 3) {
            return true;
        } else {
            return false;
        }
    }

    ValidateAge(age) {
        if (age > 18) {
            return true;
        } else {
            return false;
        }
    }
}

While the new class DisplayPerson will now be responsible for displaying a person, as you can see in the code block below:

class DisplayPerson {
    constructor(name, age) {
        this.name = name;
        this.age = age;
        this.validate = new ValidatePerson(this.name, this.age);
    }

    Display() {
        if (
            this.validate.ValidateName(this.name) &&
            this.validate.ValidateAge(this.age)
        ) {
            console.log(`Name: ${this.name} and Age: ${this.age}`);
        } else {
            console.log('Invalid');
        }
    }
}

With this, you will have fulfilled the single-responsibility principle, meaning our classes now have just one reason to change. If you want to change the DisplayPerson class, it won’t affect the ValidatePerson class.

What is the Open-Closed Principle?

The open-closed principle can be confusing because it's a two-direction principle. According to Bertrand Meyer's definition on Wikipedia, the open-closed principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

This definition can be confusing, but an example and further clarification will help you understand.

There are two primary attributes in the OCP:

• It is open for extension — This means you can extend what the module can do.

• It is closed for modification — This means you cannot change the source code, even though you can extend the behavior of a module or entity.

OCP means that a class, module, function, and other entities can extend their behavior without modifying their source code. In other words, an entity should be extendable without modifying the entity itself. How?

For example, suppose you have an array of iceCreamFlavours, which contains a list of possible flavors. In the makeIceCream class, a make() method will check if a particular flavor exists and logs a message.

const iceCreamFlavors = ['chocolate', 'vanilla'];

class makeIceCream {
    constructor(flavor) {
        this.flavor = flavor;
    }

    make() {
        if (iceCreamFlavors.indexOf(this.flavor) > -1) {
            console.log('Great success. You now have ice cream.');
        } else {
            console.log('Epic fail. No ice cream for you.');
        }
    }
}

The code above fails the OCP principle. Why? Well, because the code above is not open to an extension, meaning for you to add new flavors, you would need to directly edit the iceCreamFlavors array. This means that the code is no longer closed to modification. Haha (that's a lot).

To fix this, you would need an extra class or entity to handle addition, so you no longer need to modify the code directly to make any extension.

const iceCreamFlavors = ['chocolate', 'vanilla'];

class makeIceCream {
    constructor(flavor) {
        this.flavor = flavor;
    }
    make() {
        if (iceCreamFlavors.indexOf(this.flavor) > -1) {
            console.log('Great success. You now have ice cream.');
        } else {
            console.log('Epic fail. No ice cream for you.');
        }
    }
}

class addIceCream {
    constructor(flavor) {
        this.flavor = flavor;
    }
    add() {
        iceCreamFlavors.push(this.flavor);
    }
}

Here, we've added a new class — addIceCream – to handle addition to the iceCreamFlavors array using the add() method. This means your code is closed to modification but open to an extension because you can add new flavors without directly affecting the array.

let addStrawberryFlavor = new addIceCream('strawberry');
addStrawberryFlavor.add();
makeStrawberryIceCream.make();

Also, notice that SRP is in place because you created a new class. 😊

What is the Liskov Substitution Principle?

In 1987, the Liskov Substitution Principle (LSP) was introduced by Barbara Liskov in her conference keynote “Data abstraction”. A few years later, she defined the principle like this:

“Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T”.

To be honest, that definition is not what many software developers want to see 😂 — so let me break it down into an OOP-related definition.

The principle defines that in an inheritance, objects of a superclass (or parent class) should be substitutable with objects of its subclasses (or child class) without breaking the application or causing any error.

In very plain terms, you want the objects of your subclasses to behave the same way as the objects of your superclass.

A very common example is the rectangle, square scenario. It’s clear that all squares are rectangles because they are quadrilaterals with all four angles being right angles. But not every rectangle is a square. To be a square, its sides must have the same length.

Bearing this in mind, suppose you have a rectangle class to calculate the area of a rectangle and perform other operations like set color:

class Rectangle {
    setWidth(width) {
        this.width = width;
    }

    setHeight(height) {
        this.height = height;
    }

    setColor(color) {
        // ...
    }

    getArea() {
        return this.width * this.height;
    }
}

Knowing fully well that all squares are rectangles, you can inherit the properties of the rectangle. Since the width and height has to be the same, then you can adjust it:

class Square extends Rectangle {
    setWidth(width) {
        this.width = width;
        this.height = width;
    }
    setHeight(height) {
        this.width = height;
        this.height = height;
    }
}

Taking a look at the example, it should work properly:

let rectangle = new Rectangle();
rectangle.setWidth(10);
rectangle.setHeight(5);
console.log(rectangle.getArea()); // 50

In the above, you will notice that a rectangle is created, and the width and height are set. Then you can calculate the correct area.

But according to the LSP, you want the objects of your subclasses to behave the same way as the objects of your superclass. Meaning if you replace the Rectangle with Square, everything should still work well:

let square = new Square();
square.setWidth(10);
square.setHeight(5);

You should get 100, because the setWidth(10) is supposed to set both the width and height to 10. But because of the setHeight(5), this will return 25.

let square = new Square();
square.setWidth(10);
square.setHeight(5);
console.log(square.getArea()); // 25

This breaks the LSP. To fix this, there should be a general class for all shapes that will hold all generic methods that you want the objects of your subclasses to have access to. Then for individual methods, you create an individual class for rectangle and square.

class Shape {
    setColor(color) {
        this.color = color;
    }
    getColor() {
        return this.color;
    }
}

class Rectangle extends Shape {
    setWidth(width) {
        this.width = width;
    }
    setHeight(height) {
        this.height = height;
    }
    getArea() {
        return this.width * this.height;
    }
}

class Square extends Shape {
    setSide(side) {
        this.side = side;
    }
    getArea() {
        return this.side * this.side;
    }
}

This way, you can set the color and get the color using either the super or subclasses:

// superclass
let shape = new Shape();
shape.setColor('red');
console.log(shape.getColor()); // red

// subclass
let rectangle = new Rectangle();
rectangle.setColor('red');
console.log(rectangle.getColor()); // red

// subclass
let square = new Square();
square.setColor('red');
console.log(square.getColor()); // red

What is the Interface Segregation Principle?

The Interface Segregation Principle (ISP) states that “a client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use”. What does this mean?

Just as the term segregation means — this is all about keeping things separated, meaning separating the interfaces.

Note: By default, JavaScript does not have interfaces, but this principle still applies. So let’s explore this as if the interface exists, so you will know how it works for other programming languages like Java.

A typical interface will contain methods and properties. When you implement this interface into any class, then the class needs to define all its methods. For example, suppose you have an interface that defines methods to draw specific shapes.

interface ShapeInterface {
    calculateArea();
    calculateVolume();
}

When any class implements this interface, all the methods must be defined even if you won't use them or if they don’t apply to that class.

class Square implements ShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }  
}

class Cuboid implements ShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }    
}

class Rectangle implements ShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }   
}

Looking at the example above, you will notice that you cannot calculate the volume of a square or rectangle. Because the class implements the interface, you need to define all methods, even the ones you won’t use or need.

To fix this, you would need to segregate the interface.

interface ShapeInterface {
    calculateArea();
}

interface ThreeDimensionalShapeInterface {
    calculateArea();
    calculateVolume();
}

You can now implement the specific interface that works with each class.

class Square implements ShapeInterface {
    calculateArea(){
        //...
    } 
}

class Cuboid implements ThreeDimensionalShapeInterface {
    calculateArea(){
        //...
    }
    calculateVolume(){
        //...
    }    
}

class Rectangle implements ShapeInterface {
    calculateArea(){
        //...
    }  
}

What is the Dependency Inversion Principle?

This principle is targeted towards loosely coupling software modules so that high-level modules (which provide complex logic) are easily reusable and unaffected by changes in low-level modules (which provide utility features).

According to Wikipedia, this principle states that:

1. High-level modules should not import anything from low-level modules. Both should depend on abstractions (for example, interfaces).

2. Abstractions should be independent of details. Details (concrete implementations) should depend on abstractions.

In plain terms, this principle states that your classes should depend upon interfaces or abstract classes instead of concrete classes and functions. This makes your classes open to extension, following the open-closed principle.

Let's look at an example. When building a store, you would want your store to make use of a payment gateway like stripe or any other preferred payment method. You might write your code tightly coupled to that API without thinking of the future.

But then what if you discover another payment gateway that offers far better service, let’s say PayPal? Then it becomes a struggle to switch from Stripe to Paypal, which should not be an issue in programming and software design.

class Store {
    constructor(user) {
        this.stripe = new Stripe(user);
    }

    purchaseBook(quantity, price) {
        this.stripe.makePayment(price * quantity);
    }

    purchaseCourse(quantity, price) {
        this.stripe.makePayment(price * quantity);
    }
}

class Stripe {
    constructor(user) {
        this.user = user;
    }

    makePayment(amountInDollars) {
        console.log(`${this.user} made payment of ${amountInDollars}`);
    }
}

Considering the example above, you'll notice that if you change the payment gateway, you won't just need to add the class – you'll also need to make changes to the Store class. This does not just go against the Dependency Inversion Principle but also against the open-closed principle.

To fix this, you must ensure that your classes depend upon interfaces or abstract classes instead of concrete classes and functions. For this example, this interface will contain all the behavior you want your API to have and doesn't depend on anything. It serves as an intermediary between the high-level and low-level modules.

class Store {
    constructor(paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }

    purchaseBook(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }

    purchaseCourse(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }
}

class StripePaymentProcessor {
    constructor(user) {
        this.stripe = new Stripe(user);
    }

    pay(amountInDollars) {
        this.stripe.makePayment(amountInDollars);
    }
}

class Stripe {
    constructor(user) {
        this.user = user;
    }

    makePayment(amountInDollars) {
        console.log(`${this.user} made payment of ${amountInDollars}`);
    }
}

let store = new Store(new StripePaymentProcessor('John Doe'));
store.purchaseBook(2, 10);
store.purchaseCourse(1, 15);

In the code above, you will notice that the StripePaymentProcessor class is an interface between the Store class and the Stripe class. In a situation where you need to make use of PayPal, all you have to do is create a PayPalPaymentProcessor which would work with the PayPal class, and everything will work without affecting the Store class.

class Store {
    constructor(paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }

    purchaseBook(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }

    purchaseCourse(quantity, price) {
        this.paymentProcessor.pay(quantity * price);
    }
}

class PayPalPaymentProcessor {
    constructor(user) {
        this.user = user;
        this.paypal = new PayPal();
    }

    pay(amountInDollars) {
        this.paypal.makePayment(this.user, amountInDollars);
    }
}

class PayPal {
    makePayment(user, amountInDollars) {
        console.log(`${user} made payment of ${amountInDollars}`);
    }
}

let store = new Store(new PayPalPaymentProcessor('John Doe'));
store.purchaseBook(2, 10);
store.purchaseCourse(1, 15);

You will also notice that this follows the Liskov Substitution Principle because you can replace it with other implementations of the same interface without breaking your application.

Ta-Da 😇

It's been an adventure🙃. I hope you noticed that each of these principles are related to the others in some way.

In an attempt to correct one principle, say the dependency inversion principle, you indirectly ensure that your classes are open to extension but closed to modification, for example.

You should keep these principles in mind when writing code, because they make it easier for many people to collaborate on your project. They simplify the process of extending, modifying, testing, and refactoring your code. So make sure you understand their definitions, what they do, and why you need them beyond OOP.

For more understanding, you can watch this video by Beau Carnes on the freeCodeCamp YouTube channel or read this article by Yiğit Kemal Erinç.

Have fun coding!

You can access over 200 of my articles by visiting my website. You can also use the search field to see if I've written a specific article.

Here is what each letter in the acronym stands for:

• S: Single responsibility principle.
• O: Open–closed principle.
• L: Liskov substitution principle.
• I: Interface segregation principle.
• D: Dependency inversion principle.

In this article, we'll start by defining each principle and then we'll see some examples to help you understand how and why you should use these principles in your code.

The examples we will use in this article are going to be very basic. We will be using Java for our examples.

We'll conclude this article by talking about the basics of object oriented design.

The Single Responsibility Principle (SRP)

The idea behind the SRP is that every class, module, or function in a program should have one responsibility/purpose in a program. As a commonly used definition, "every class should have only one reason to change".

Consider the example below:

public class Student {

     public void registerStudent() {
         // some logic
     }

     public void calculate_Student_Results() {
         // some logic
     }

     public void sendEmail() {
         // some logic
     }

}

The class above violates the single responsibility principle. Why?

This Student class has three responsibilities – registering students, calculating their results, and sending out emails to students.

The code above will work perfectly but will lead to some challenges. We cannot make this code reusable for other classes or objects. The class has a whole lot of logic interconnected that we would have a hard time fixing errors. And as the codebase grows, so does the logic, making it even harder to understand what is going on.

Imagine a new developer joining a team with this sort of logic with a codebase of about two thousand lines of code all congested into one class.

Now let's fix this!

public class StudentRegister {
    public void registerStudent() {
        // some logic
    }
}

public class StudentResult {
    public void calculate_Student_Result() {
        // some logic
    }
}

public class StudentEmails {
    public void sendEmail() {
        // some logic
    }
}

Now we've separated each functionality in our program. We can call the classes anywhere we want to use them in our code.

The examples we used use just showed each class having one method – this is mainly for simplicity. You can have as many methods as you want but they should be linked to the responsibility of the class.

Now that we have separated the logic, our code is easier to understand as each core functionality has its own class. We can test for errors more efficiently.

The code is now reusable. Before, we could only use these functionalities inside one class but now they can be used in any class.

The code is also easily maintainable and scalable because instead of reading interconnected lines of code, we have separated concerns so we can focus on the features we want to work on.

Open–Closed Principle (OCP)

The open-closed principle states that software entities should be open for extension, but closed for modification.

This implies that such entities – classes, functions, and so on – should be created in a way that their core functionalities can be extended to other entities without altering the initial entity's source code.

In the example below, we're going to write the code for calculating the body mass index (BMI) of a person:

public class Human  {

     public int height;
     public int weight;

}

We've created the Human class which provides the height and width properties of the class. Now, let's calculate the first person's BMI.

public class CalculateBMI {

     public int CALCULATE_JOHN_BMI(Human John) {   

         return John.height/John.weight;

     }
}

We've calculate the BMI of a person named John. We'll go on and calculate the BMI for a person named Jane.

public class CalculateBMI {

     public int CALCULATE_JOHN_BMI(Human John) {   

         return John.height/John.weight;

     }

     public int CALCULATE_JANE_BMI(Human Jane) {   

         return Jane.height/Jane.weight;

     }
}

The problem with this is that we keep modifying the code every time we need to calculate the BMI of another person.

This also violates the SRP because the class now has more than one reason to change.

Although the code above may work perfectly, it's not efficient. We modify the code constantly which may lead to bugs. And the code only has provision for humans. What if we have to calculate for an animal or an object?

Let's fix the problem using the open-closed principle.

public interface Entity {

     public int CalculateBMI();

}

// John entity
public class John implements Entity {

     int height;
     int weight;

     public double CalculateBMI() {

           return John.height/John.weight;
     }
}

// Jane entity
public class Jane implements Entity {

     int height;
     int weight;

     public double CalculateBMI() {

           return Jane.height/Jane.weight;
     }
}

// Dog entity
public class Dog implements Entity {

     int height;
     int weight;

     public double CalculateBMI() {

           return Dog.height/Dog.weight;
     }
}

In the code above, we have created an interface called Entity with a CalculateBMI() method.

Each entity – John, Jane and Dog – extends the functionality of the Entity interface.

Now we no longer have to modify existing code when we create a new entity - we just extend the functionality we need and apply it to the new entity.

Next, we'll talk about the Liskov Substitution Principle.

Liskov Substitution Principle (LSP)

According to Barbara Liskov and Jeannette Wing, the Liskov substitution principle states that:

Let Φ(x)_ be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. (Source:_ Wikipedia)

Don't worry if you find that confusing, it will all make sense soon. Let's simplify this principle below:

The Liskov substitution principle simply implies that when an instance of a class is passed/extended to another class, the inheriting class should have a use case for all the properties and behavior of the inherited class.

Let's say we have a class called Amphibian for animals that can live on both land and water. This class has two methods to show the features of an amphibian – swim() and walk().

public class Amphibian {

    public void swim();
    public void walk();

}

The Amphibian class can extend to a Frog class because frogs are amphibians, so they can inherit the properties of the Amphibian class without altering the logic and purpose of the class.

public class Frog extends Amphibian {
    public void swim() {
        System.out.println("The frog is swimming");
    }

    public void walk() {
        System.out.println("The frog is walking on land");
    }
}

But we cannot extend the Amphibian class to a Dolphin class because dolphins only live in water which implies that the walk() method would be irrelevant to the Dolphin class.

So, when you extend a class, if some of the properties of the initial class are not useful for the new class, the Liskov substitution principle has been violated.

The solution to this is simple: create interfaces that match the needs of the inheriting class.

In summary, if a class inherits another, it should do so in a manner that all the properties of the inherited class would remain relevant to its functionality.

Interface Segregation Principle (ISP)

The interface segregation principle states that the interface of a program should be split in a way that the user/client would only have access to the necessary methods related to their needs.

To understand this better, we'll first look at an example that violates the ISP:

public interface Teacher {

    void English();

    void Biology();

    void Chemistry();

    void Mathematics();

}

We've created an interface called Teacher which has various subjects as its methods. Let's extend this interface to our first teacher.

public class Jane implements Teacher {

    @Override
    public void English() {
        System.out.println("Jane is teaching the students English language.");
    }

    @Override
    public void Biology() {
    }

    @Override
    public void Chemistry() {
    }

    @Override
    public void Mathematics() {
    }
}

From the code above, you can tell that Jane is an English teacher who has no business with the other subjects. But these other methods are extended by default with the Teacher interface.

Do not confuse the Liskov substitution principle and the interface segregation principle. They may seem similar but they are not entirely the same.

Liskov substitution principle gives us the idea that when a new class has the need to inherit an existing class, it should do so because this new class has a need for the methods the existing class has.

On the other hand, the interface segregation principle makes us understand that it is unnecessary and unreasonable to create an interface with a lot of methods as some of these methods may be irrelevant to the needs of a particular user when extended.

Now let's fix the code in the last example.

public interface Teacher {

    void Teach();

}

The Teacher interface now has only one method. Let's go on and extend this interface to support the different subjects.

// English teacher interface

public interface EnglishTeacher extends Teacher {

    void English();

}

// Biology teacher interface

public interface BiologyTeacher extends Teacher {

    void Bilogy();

}

// Chemistry teacher interface

public interface ChemistryTeacher extends Teacher {

    void Chemistry();

}

// Mathematics teacher interface

public interface MathematicsTeacher extends Teacher {

    void Mathematics();

}

We have created different interfaces for every subject. Now Jane can teach English without carrying the other methods with them. Here is an example:

public class Jane implements EnglishTeacher {

    @Override
    public void Teach() {
        System.out.println("Jane has started teaching.");
    }

    @Override
    public void English() {
        System.out.println("Jane is teaching the students English language.");
    }

}

Dependency Inversion Principle (DIP)

The dependency inversion principle states:

High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces). (Source: Wikipedia).

And,

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. (Source: Wikipedia).

Let's use a real-life example before writing some code.

Imagine taking a one minute walk to the bank every time you had to withdraw money over the counter. It then takes an extra thirty seconds for you get your money. This is quite efficient because very little time is wasted. We'll assume you're the high-level module and the bank is the low-level module.

But what happens when the bank is closed for a holiday or an emergency? You have absolutely no access to your funds. If you move further away from the bank, it becomes a bigger problem because you'd spend more time getting there.

To solve this problem, an interface is introduced – an automated teller machine (ATM) or a mobile banking app. Even though you have a relationship with the bank, you are no longer required to interact with them physically to be served.

This example is similar to the dependency inversion principle. We should make our classes rely on properties in our interfaces instead of relying on each other.

The implications of violating this principle would result in a rigid system where testing blocks of code independently would be very difficult, reusability of code would be near impossible, and the addition or removal of code would lead to further complexity of the system and introduce bugs.

Here is a code example that violates this principle:

public class Bank {

    public void GIVE_CUSTOMER_MONEY_OTC() {
        // some logic
    }
}

public class Customer {
    private Bank myBank = new Bank();

    public void withdraw() {
        myBank.GIVE_CUSTOMER_MONEY_OTC();
    }
}

From the code examples above, we can see that the Customer class imports and relies on a method in the Bank class. This reliance on a low-level class is against the DIP.

Like in our real-life example, we'll solve this problem by introducing an interface that both classes can interact with.

Here's the ATM interface that our Bank and Customer class will interact with:

public interface ATM {
    void ATM_OPERATION();
}

Here's the Bank class which uses a method in the ATM interface to add money to the ATM:

public class Bank implements ATM {
    @Override
    ATM_OPERATION(){
        // code to add money to ATM and increase the ATM balance
    }
}

Lastly, the Customer class which uses the same interface to withdraw money:

public class Customer implements ATM {

    @Override
    ATM_OPERATION(){
        // code to withdraw money from ATM and decrease the ATM balance
    }
}

What Is Object Oriented Design?

Object oriented design is a design methodology for building object-based systems and applications. This enables us to build systems with a collection of objects where each object has its own properties and methods.

Take the computer system as an example. Its hardware is made up of different parts that comprise the whole system.

Here are some of the general terms associated with object oriented design:

• Objects: Each separate unit that makes up the system is an object. Objects can have properties and methods.
• Classes: Classes act as a general description for objects. So an object is an instance of a class.
• Encapsulation: this aids in bundling all the relevant data of an object in one unit. This also helps in restricting access to specific data and methods which should only be found in one object.
• Inheritance: Inheritance makes it easier for us to extend the functionality of a class to other classes. This way, we do not repeat the process of creating these functionalities over and over again.
• Abstraction: This means showing only important attributes and hiding the irrelevant ones.
• Polymorphism: This is the existence of an interface in various forms. The ability to extend an object/interface but with different or addition attributes.

Conclusion

There are so many ways to solve a problem. But there are also many ways to create problems from a solution.

The more rigid and coupled the classes and methods in our code are, the more difficult it would be to maintain and reuse our code.

Neglecting or violating these principles could pose a serious threat to not just the codebase and the developer, but to the organization that owns the product as well.

A rigid and tightly coupled codebase makes it difficult to add or remove features in a product, test and reuse blocks of code, and introduces possible breaking changes with every code modification made.

The SOLID principles act as a guide to help us create a flexible and dynamic product and we went over each principle in this article to help us understand how the objects we create should interact which each other.

I hope you find this article helpful as you continue your journey through object oriented design.

Happy coding!