SOLID* Design Principles (by Robert C. Martin)

Single Responsibility Principle (SRP) / Separation of Concerns

A class is responsible for doing only one thing. Why? The code is cleaner, easier to maintain, and reusable. For example, instead of having a class storing data and persisting it in a file, we can create two classes: a store class and a persistence class.

Open-Closed Principle (OCP)

A class should be open for inheritance, but closed for modification. For example, we want to create a chef class that can make meals. We could define methods like makePizza(), makeCurry(), etc. but it would violate the OCP. Each time, we would need to modify the chef class each time we need to add a new type of meal. A better design would be:

class Chef() {
   Meal make(pizza, recipe);
}

In this case, we do not need to modify chef if we want another type of meal. We would simply give a different recipe. We can also extend Chef if we want to have a FasterChef or FancyChef, etc.

Liskov Substitution Principle (LSP)

A parent class should be substitutable by a subclass. Or according to Barbara Liskov – which is clearer to me :

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.

Why? to guarantee that the subclass follow the same behavior as its parent, and to avoid introducing bugs by overriding methods.

class Car() {
   boolean engineOn; // default value = false

   void turnKey() {
     engineOn = true;
   }

   void start() {
      turnKey();
   }

   boolean isOn() {
     return engineOn;
   }
}

class Ferrari() extends Car {
   void start() {
     pressButton(); // no key
   }
   ...
}

class Driver() {
   void use(Car car) {
      car.start();
      if (!car.isOn()) {
        System.out.println("Not working...") 
      }
   }
}

driver.use(ferrari) -> would write "Not working..." because the subclass does not extend its parent's behavior properly which means it is not substitutable.

Interface Segregation Principle (ISP)

An interface must only include methods defining a specific behavior. Or in other words: YAGNI = You Ain’t Going to Need It! Why? to avoid unclear and unimplemented methods when not needed.

Let’s say we want to create a Car interface:

public interface Car {
  void start();
  void drive();
  void removeSeats();
}

This interface may work for a MiniVan class, but not for a Coupe:

public class MiniVan implements Car {
  void start() {
    // do something
  }

  void drive() {
    // do something
  }

  void removeSeats() {
    // do something
  }
}

public class Coupe implements Car {
  void start() {
    // do something
  }

  void drive() {
    // do something
  }

  void removeSeats() {
    // do NOTHING! --> cannot remove seats in a coupe
  }
}

It is better to define two interfaces defining its own behavior:

public interface Drivable {
  void start();
  void drive();
}

public interface Expandable {
  void removeSeats();
}

// As result, we have:
public class MiniVan implements Drivable, Expandable ...
public class Coupe implements Drivable ...

Dependency Inversion Principle (DIP)

This principle (not to be confused with dependency injection) has two parts:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

The purpose is to avoid dependency from high-level modules on low-level modules. Otherwise, changes on those low-level modules imply refactoring high-level modules. In summary:

High-Level modules -> Interfaces/Abstractions -> Low-Level modules

Let’s say we want to write a reader class (high-level) that represents someone who reads a book.

class Reader {
  private Book book;
  private int currentPage;

  void openBook(Book book) {
     this.book = book;
     this.currentPage = book.open();
  }

  void read() {
     String text = book.readPage(currentPage);
  }

  void turnPage() {
     currentPage++;
     book.gotToPage(currentPage);
  }

}

This class relies on a Book class (low-level):

class Book {
  int open() { ... }
  String readPage() { ... }
  void goToPage() { ... }
}

Now, what happens if instead of a book, our reader wants to read a PDF? or a eBook? or anything else that is readable? We would need to refactor our Reader class. A better version of our code would be:

interface Readable { // our abstraction layer between high and low level
   void open();
   String read(int size);
   void goTo(int location);
}

class Reader {
   private Readable material;
   private int location;
   private final int sizeIcanHandle = 1000;

   void openBook(Readable material) {
     this.material = material;
     this.location = material.open();
   }

   void read() {
     String text = material.read(sizeIcanHandle);
   }

   void next() {
     location += sizeIcanHandle;
     material.gotTo(location);
   }
}

Book, eBook, PDF, etc. classes can implement the Readable interface, and Reader would not need to be rewritten.

Now in real life, I have often seen a multitude of interfaces with only one implementation. Of course, one day we may need another implementation, but most of the time, it sits there and we are not going to need another implementation (by the time we do, we may have already been in an effort to rewrite the whole application), or the interface needs rework (because we do not plan well for unknown future) and debugging becomes tedious. I do not mean to say abstractions are useless, but I sometimes wonder about the benefits vs the costs. Do we really need to be “systematic” in our coding approach? Again, coding is a bit artsy, no matter what developers may say…

*Now you should know what SOLID stands for.

Author: Toujon Lyfoung

This paragraph is supposed to be the place where I put my credentials and achievements. In my opinion, degrees and jobs do not tell much about a person. If you want to know me, read my posts! Blogging has been fun. I do not pretend to do much. I am simply processing, tracking and sharing my reflection. Comments are definitely welcomed to help me continue in my learning.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s