This article will briefly review the importance of applying good practices in projects and then give a quick overview of the SOLID principles.

Why Bother

Have you ever wondered why you should care about good practices? Or what could happen if you don’t apply them to the project? And how can you ensure your code is good enough? So let’s try to explore these subjects.

I want to start with this phrase: “The ritual lasts long after the reasons have been forgotten”. This means that it is common for humans to do many things without understanding the reasons behind them. As Jordan Peterson once said: "It’s like waking up one day and noting that you don’t know why you put a Christmas tree up, but you have been doing it for a long time, and that is what people do, and you know there are reasons that the Christmas tree came about." We do this in our lives, and we also do this in our projects. How many times have you copied code from someone else’s project? Or from the internet? We’ve all probably done it. So this is the first point: Ask yourself why something is done the way it is.

And now let’s talk a little about money. Developers often don’t think about this subject, but it’s essential to have a view from all angles, including the perspective of the company that hired you to develop the project.

Let me tell you a little story. I started working on our team’s biggest project when I joined a company. And they said it was the sales champion, the most profitable project. But today, I see that the project failed. The developers of that project failed. And you might think: But what do you mean? Isn’t it the team’s biggest, most profitable, and best seller? And yes, that is correct, but now let me explain this further. It turns out that the project was complicated to maintain. Any adjustments we had to make sometimes took hours or days. In other words, the project was very costly to maintain. And the proof of this is that we started to develop a new project, to do the same thing this other project was already doing. So this is a consequence of a project that did not follow good practices.

So we have to consider that developing software is expensive. And I can’t finish it and never touch it again. It needs constant maintenance, as it needs to keep up with the evolution of the business. And for the software to be profitable, it needs to stay in the running for as long as possible because the longer this running time is, the more return it generates. And to achieve all of this, the project needs a well-architected solution.

Another thing we do is: make mistakes. And this is no different with new projects. And we must make many mistakes before we can create a solution that will meet all the points we’ve already discussed. And those mistakes can be costly, and they often are. No wonder most projects fail because of high maintenance costs. So how can we ensure we don’t make the same mistakes? Well, there is a shortcut that we can use, which allows us to reach the results we want quickly, that is, making good software. So let’s delve deeper into this subject.

We often sink in the mud, but there is already a path that will help us, but we are not seeing it. And this path has been shown to us by people who have already made many mistakes in the past. So what we can do is: learn from the mistakes of others. This is our shortcut. So if you look at design patterns, you’ll see that they’re the solution to many of the problems other people have had. And we must use them, so we don’t make the same mistakes.

In fact, the book Clean Code, written by Robert C. Martin, aka Uncle Bob, is an example of this. The first edition began to be written in the 90s and was published a little later. And as Uncle Bob himself said, he didn’t create all the rules. At that time, it was common to use forums to exchange ideas and talk with others. Using the forums a lot, he realized that several people had some problems and that, in the end, everyone came to similar solutions. So what he started to do was to group these problems and solutions in one place. So many of the patterns that we have today are years of experience of people making mistakes and coming to the same conclusions. So we don’t have to make the same mistakes. We can identify our problem and apply a solution, that is, some design pattern. And SOLID is a good start.

So keep in mind that If the software doesn’t think about being sustainable from day zero, it can generate a nightmare for the company and, in the end, could be loss-making.

This was an introduction to show the importance of good practices, how design patterns can help us, and what can happen if we don’t use them. So, now that you know this, let’s start talking about SOLID.

SOLID

When we are talking about software architecture, we are talking about several pillars, and one of these pillars is: how you code. And we have different ways of programming, and one of those ways is using object orientation. And because of that, we have several good programming practices. SOLID is an acronym that consolidates five items that are considered good practices in the world of object-oriented development. So let’s see each of them, why to use them, and what problems each one solves, and give some practical examples.

S — Single Responsibility Principle

A class should have only one responsibility. It can’t do more things than it was created to do. When you put too much to do inside the class, you are hurting this principle and complicating the way you work with object orientation. We can also apply this to methods, so each method needs to do only one thing.

Let’s take a look at the example below. We have a Movie class with name and category attributes and connection and createCategory methods. However, in this example, this is a Model class, that is, a class that contains our attributes and should probably be an anemic class (without any methods). So the connection method, which connects to the database, and the createCategory method, which saves the category in the database, are not respecting this principle, as they are doing things that the class was not created to do. Therefore, connecting to the database and saving the category is not the responsibility of this class.

class Movie {
    private String name;
    private Category category;

    public Connection connection() {
        return new Connection();
    }

    public void createCategory() {
        this.connection().insert(this.category);
    }

    // getters and setters
}

So we have to move to other classes the methods that don’t fit. We will have two new classes if we use the MVC (Model-View-Controller) pattern to refactor this class. First, we create the Service class, responsible for our logic to create the category, which will receive the createCategory method. Then, we create the Repository class, which is responsible for connecting to the database, and which will receive the connection method.

class Movie {
    private String name;
    private Category category;

    // getters and setters
}

class Service {
    private Repository repository;

    // The createCategory method is now inside the Service.
    public void createCategory(Category category) {
        repository.createCategory(category);
    }
}

class Repository {
    public void createCategory(Category category) {
        this.connection().insert(category);
    }

    // The connection method is now inside the Repository.
    public Connection connection() {
        return new Connection();
    }
}

O — Open Closed Principle

Every class has to be open for extension and closed for modification. Every time you need to add a new behavior, you increase the class size by adding new conditions. When you apply this principle, instead of creating a class and every time you change some requirement, you have to keep changing and incrementing this class, you make a base of this class, and every time you need to modify or add something new, you extend the behavior. Instead of putting everything inside the same class, you create different objects and make the system more extensible, taking better advantage of object-oriented resources. You work with objects and make them talk with each other.

In the example below, we have the Movie class with a category and a price. We have the calculatePrice method, which has a simple logic to calculate the price depending on the movie category. I know this might not make sense, and we should avoid using constants in our code, but the idea here is to use a simple example to demonstrate this principle in practice. So if the category is Action, we double the movie price. If the category is Drama, we increase the price by 50%. Now, what if we need to add one more category? What if now we also have Comedy? We have to add one more if statement. Every time I need to add a new category, I must remember to adjust the calculatePrice method. And it gets worse and worse because this method only tends to grow in size. This class is plastered because I always need to modify it. But the idea is that the class is closed for modification, but at the same time, we can open this class for extension.

class Movie {
    private Category category;
    private double price;

    public double calculatePrice() {
        if (category.getName().equals("Action")) {
            return price * 2;
        } else if (category.getName().equals("Drama")) {
            return price * 1.5;
        }
        return price;
    }

    // getters and setters
}

The abstract class cannot be instanciated. It ends up becoming a model. I create Action and Drama classes, which extend from Movie and which have the calculatePrice method implementation. Every time I need to calculate the price of a Movie, I instantiate an Action or Drama class and call the calculatePrice method. I don’t need to modify the Movie class all the time. Instead, I extended the class and added the behavior. It is much simpler to change the code and more organized. Every time I need to add a new category, I extend the class.

abstract class Movie {
    Category category;
    double price;

    public abstract double calculatePrice();

    // getters and setters
}

class Action extends Movie {
    public double calculatePrice() {
        return price * 2;
    }
}

class Drama extends Movie {
    public double calculatePrice() {
        return price * 1.5;
    }
}

L — Liskov Substitution Principle

Liskov comes from the name Barbara Liskov, who was the woman who created this idea. What is it for? The idea is that subclasses can be replaced by their parent classes. Every time a class extends from another class, you must be able to replace the child class with the parent class. This parent class can be used at any time in place of the child class. If it cannot be used, you are violating this principle.

In this example, we have our Movie class again, with play and increaseVolume methods. And we created two movies: TheLionKing and ModernTimes. The first is a very famous movie, surely you know it. The second film is an old Charlie Chaplin film from the year 1936. This was a time when films were usually silent, so this film had no sound. So maybe you already realized what the problem is: How are we going to increase the volume of a movie that has no sound? That is, how will the ModernTimes class implement the increaseVolume method? In these cases, developers usually leave the method blank, add a comment or throw an exception, which is what I did.

class Movie {
    public void play() {}
    public void increaseVolume() {}
}

class TheLionKing extends Movie {}

class ModernTimes extends Movie {
    @Override
    public void increaseVolume() {
        throw new UnsupportedOperationException("This movie is silent");
    }
}

Although TheLionKing and ModernTimes are movies, they both implement the increaseVolume method, but only TheLionKing can use it. This is because ModernTimes looks like a movie, has images like a movie, and shows scenes like a movie, but in the current context, all movies have volume. But ModernTimes is silent and cannot extend from the Movie class because the increaseVolume method will not work. This error is difficult to detect because, as we see in the image below, we can replace both child classes with the parent class without generating any compilation errors since both classes follow the Object-Oriented polymorphism rule, which is to extend from the same class. However, when trying to execute the method increaseVolume of the ModernTimes class, we will have an error at runtime or, in cases where the method is blank, a logic problem, as we expect something to happen, but nothing happens. The next principle will help us solve this problem.

public void watchMovies() {
    Movie movie;

    movie = new TheLionKing();
    playMovie(movie);

    movie = new ModernTimes();
    playMovie(movie); // It will not work
}

public void playMovie(Movie movie) {
    movie.play();
    movie.increaseVolume();
}

I — Interface Segregation Principle

A class is not required to implement interfaces that it will not use. For example, we often have a class that implements an interface with several methods my class will need to implement. Now imagine that I need to implement only two of the three interface methods. In the other method, you will put a comment, leave it blank, or throw an exception. And that’s the problem. So, you should only implement interfaces that your class will use. So if you have an interface with a method you’re not going to use, you create a new one with just that method. That is, you segregate this interface.

In the example below, we can see an example very similar to the previous principle. The ModernTimes class needs to implement the increaseVolume method, even if the method is not used. However, the ModernTimes class shouldn’t be forced to implement a method that it won’t use just to be able to implement the interface. So to solve this problem, let’s segregate the interface by moving the increaseVolume method somewhere else.

interface Movie {
    void play();
    void increaseVolume();
}

class TheLionKing implements Movie {
    @Override public void play() {}
    @Override public void increaseVolume() {}
}

class ModernTimes implements Movie {
    @Override public void play() {}
    @Override public void increaseVolume() {
        // method not used
    }
}

The Movie interface was divided into two interfaces, creating a new AudioControl interface with only the increaseVolume method. Now TheLionKing class can extend from both Movie and AudioControl interfaces and implement play and increaseVolume methods. And the ModernTimes class only extends from the Movie interface and implements only the play method. That is, now it is no longer required to implement the increaseVolume method. Now classes only implement the methods they are going to use.

interface Movie {
    void play();
}

interface AudioControl {
    void increaseVolume();
}

class TheLionKing implements Movie, AudioControl {
    @Override public void play() {}
    @Override public void increaseVolume() {}
}

class ModernTimes implements Movie {
    @Override public void play() {}
}

Dependency Inversion Principle

This principle says that we should depend on abstractions and not on implementations. When we talk about implementation, we are talking about a concrete class when you use the new word to create an object from the class. The abstraction is a model of our class. So, we must depend on a model, which can be an interface or an abstract class that cannot be instantiated.

Looking at the code below, it seems nothing is wrong at first glance. I have the Movie class, and it has the DramaCategory class. The problem is that the DramaCategory class specifically implements a drama-type category. So the Movie class can only have drama types. So if I create another category like Action or Comedy, it won’t work. This creates a tight coupling, and it’s right for the Movie class to use the Category class, not the other way around. So we must invert how this dependency works and remove this specific DramaCategory implementation.

class DramaCategory {}

class Movie {
    String name;
    DramaCategory category;

    public DramaCategory getCategory() {
        return category;
    }

    public void setCategory(DramaCategory category) {
        this.category = category;
    }

    // getters and setters
}

So what we did was create a Category interface, and I have the DramaCategory class implement that interface. Now I add this to my constructor, signaling the calling method that I depend on a category type and that it needs to provide me with an implementation. Now the calling method is responsible for providing that dependency, and I can work with any category that implements the interface. If I want to add the ActionCategory, I implement the Category interface and provide this class when I’m instantiating the Movie class. So now the control is inverted because I need to pass my dependency when creating my object.

public void watchMovies() {
    Movie dramaMovie = new Movie("The Godfather", new DramaCategory());
    Movie actionMovie = new Movie("The Rock", new ActionCategory());
}

interface Category {}
class DramaCategory implements Category {}
class ActionCategory implements Category {}

class Movie {
    String name;
    Category category;

    public Movie(String name, Category category) {
        this.name = name;
        this.category = category;
    }

    // getters and setters
}

Summary

See the summary below on each of the principles:

Single Responsibility Principle

Problem: A class should have only one responsibility.

Solution: Move to other classes the methods that don’t fit.

Open Closed Principle

Problem: Every class has to be open for extension and closed for modification.

Solution: Extend the behavior without changing the parent class.

Liskov Substitution Principle

Problem: Subclasses must be replaceable by their parent classes.

Solution: Don’t implement methods you’re not going to use.

Interface Segregation Principle

Problem: A class should not implement methods that will not be used.

Solution: Move unused methods to a new interface.

Dependency Inversion Principle

Problem: Rely on abstractions, not implementations.

Solution: Invert dependencies, receiving an abstraction in the constructor

Conclusion

Developing software is expensive, and if we are not careful, it can become a nightmare for the company, even causing money losses. And indeed, most projects fail because of the high maintenance cost. So to reduce this cost and have maintainable software, we need to think about a good software architecture. SOLID is a good start to having a well-defined architecture. By applying its principles, you will have software that is easy to maintain and will allow it to keep up with the evolution of the business.

References

Free images. https://www.pexels.com. Accessed February 2023.

The S.O.L.I.D Principles in Pictures. https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898. Accessed February 2023.