Design patterns and principles

Software development is a process that is not only about writing code, regardless of whether you are working in a large team or on a one-person project. The way an application is structured has a huge impact on how successful a software application is.

When we are talking about a successful software application, we are not only discussing how the application does what it's supposed to do but also how much effort we put into developing it, and if it's easy to test and maintain. If this is not done in a correct manner, the skyrocketing development cost will result in an application that nobody wants.

Software applications are created to meet needs, which are constantly changing and evolving. A successful application should also provide an easy way through which it can be extended to meet the continuously changing expectations.

Luckily, we are not the first to encounter these problems. Some of the problems have already been faced and handled. These common problems can be avoided or solved if a set of object-oriented design principles and patterns are applied while designing and developing software.

The object-oriented design principles are also called SOLID. These principles are a set of rules that can be applied when designing and developing software, in order to create programs that are easy to maintain and develop. They were first introduced by Robert C. Martin, and they are part of the agile software-development process. The SOLID principles include the single responsibility principle, open/closed principle, Liskov Substitution Principle, Interface Segregation Principle, and dependency inversion principle.

In addition to the design principles, there are object-oriented design patterns. Design patterns are general reusable solutions that can be applied to commonly occurring problems. Following Christopher Alexander's concept, design patterns were first applied to programming by Kent Beck and Ward Cunningham, and they were popularized by the so-called Gang Of Four (GOF) book in 1994. In the following section, we will present the SOLID design principles, which will be followed by the design patterns in the next chapters.

Single responsibility principle

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:

Open/closed principle

This principle is as follows:

"Modules, classes, and functions should be open for extension but closed for modifications."

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.

 

Liskov Substitution Principle

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.

Interface Segregation Principle

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

"Clients should not be forced to depend upon interfaces that they don't use."  

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:

Dependency inversion principle

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

"Abstractions should not depend on details. Details should depend on abstractions."

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: