The single responsibility principle is an object-oriented design principle that states that a software module should have only one reason to change. In most cases, when writing Java code, we will apply this to classes.

The single responsibility principle can be regarded as a good practice for making encapsulation work at its best. A reason to change is something that triggers the need to change the code. If a class is subject to more than one reason to change, each of them might introduce changes that affect others. When those changes are managed separately but affect the same module, one set of changes might break the functionality related to the other reasons for change.

On the other hand, each responsibility/reason to change will add new dependencies, making the code less robust and harder to change.

In our example, we will use a database to persist the objects. Let's assume that, for the Car class, we will add methods to handle the database operations of create, read, update, and delete, as shown in the following diagram:

In this case, the Car will not only encapsulate the logic, but also the database operations (two responsibilities are two reasons to change). This will make our classes harder to maintain and test, as the code is tightly coupled. The Car class will depend on the database, so if in the future we want to change the database system, we have to change the Car code. This might generate errors in the Car logic.

Conversely, changing the Car logic might generate errors in the data persistence.

The solution would create two classes: one to encapsulate the Car logic and the other to be responsible for persistence:

This principle is as follows:

Applying this principle will help us to develop complex and robust software. We must imagine the software we develop is building a complex structure. Once we finish a part of it, we should not modify it any more but build on top of it.

When developing software, it's the same. Once we have developed and tested a module, if we want to change it, we must test not only the functionality we are changing but the entire functionality it's responsible for. That involves a lot of additional resources, which might not have been estimated from the beginning, and also can bring additional risks. Changes in one module might affect functionality in others or on the whole. The following is a diagrammatic representation:

For this reason, best practice is to try to keep modules unchanged once finished and to add new functionality by extending them using inheritance and polymorphism. The open/closed principle is one of the most important design principles being the base for most of the design patterns.

Barbara Liskov states that, Derived types must be completely substitutable for their base types. The Liskov Substitution Principle (LSP) is strongly related to subtyping polymorphism. Based on subtyping polymorphism in an object-oriented language, a derived object can be substituted with its parent type. For example, if we have a Car object, it can be used in the code as a Vehicle.

The LSP states that, when designing the modules and classes, we must make sure that the derived types are substitutable from a behavior point of view. When the derived type is substituted with its supertype, the rest of the code will operate with it as it is the subtype. From this point of view, the derived type should behave as its supertype and should not break its behavior. This is called strong behavioral subtyping.

In order to understand the LSP, let's take an example in which the principle is violated. While we are working on the car-service software, we discover we need to model the following scenario. When a car is left for service, the owner leaves the car. The service assistant takes the key and, when the owner leaves, he goes to check that he has the right key and that he has spotted the right car. He simply goes to unlock and lock the car, then he puts the key in a designated place with a note on it so the mechanic can easily pick it up when he has to inspect the car.

We already have defined a Car class. We are now creating a Key class and adding two methods into the car class: lock and unlock. We add a corresponding method, so the assistant checks the key matches the car:

public class Assistant
{
  void checkKey(Car car, Key key)
  {
    if ( car.lock(key) == false ) System.out.println("Alert! Wrong 
    key, wrong car or car lock is broken!");
  }  
}

The diagram is as follows:

While working on our software, we realize that buggies are sometimes repaired through the car service. As buggies are four-wheel cars, we create a Buggy class, which is inherited from the Car:

Buggies don't have doors, so they cannot be locked or unlocked. We implement our code accordingly:

public bool lock(Key key)
{
  // this is a buggy so it can not be locked return false;
}

We design our software to work with cars, regardless of whether they are buggies or not, so in the future we might extend it with other types of cars. A problem may arise from the fact that cars are expected to be locked and unlocked.

The following quote is taken from https://www.oodesign.com/interface-segregation-principle.html link:

When applied, the Interface Segregation Principle (ISP) reduces the code coupling, making the software more robust, and easier to maintain and extend. ISP was first announced by Robert Martin, when he realized that if the principle is broken and clients are forced to depend on interfaces they don't use, the code becomes so tightly coupled that it's almost impossible to add new functionality to it.

In order to better understand this, let's again take the car-service example (refer to the following diagram). Now we need to implement a class named Mechanic. The mechanic repairs cars, so we add a method of repair car. In this case, the Mechanic class depends upon the I class. However, the Car class exposes a richer sets of methods than the Mechanic class needs:

This is a bad design because if we want to replace a car with another one, we need to make changes in the Mechanic class, which violates the open/closed principle. Instead, we must create an interface that exposes only the relevant methods required in the Mechanic class, as shown in the following diagram:

In order to understand this principle, we must explain the important concept of coupling and decoupling. Coupling refers to the degree to which modules of a software system are dependent on one another. The lower the dependency is, the easier it is to maintain and extend the system.

There are different approaches to decoupling the components of a system. One of them is to separate the high-level logic from the low-level modules, as shown in the following diagram. When doing this, we should try to reduce the dependency between the two by making them depend on abstractions. This way, any of them can be replaced or extended without affecting other modules: