We have now reached the grande finale of the blog series on SOLID, the big D, The Dependency-Inversion Principle. Let’s jump right into it.

Definition

The Dependency Inversion Principle (DIP) states:

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

B: Abstractions should not depend upon details. Details should depend upon abstractions.

This needs some explaining. More traditional software development methods tend to create software structures in which high-level modules depends on low-level modules. DIP says these dependencies should be exchanged with abstractions. I’ll show you an example on how this can be done in the ”How to implement” section.

We must also define ”high-level” and ”low-level” in order to understand this properly. I like to define high-level modules as close to the Domain/Business logic and low-level as those close to the input and output of the program. A typical high-level module contains the domain models while a typical low-level module contains code that deals with I/O (for example reading user input commands or persisting data to a database).

Code smells

Code that does not adhere to DIP can be hard to change and re-use. In other words it smells of Rigidity and Immobility. The smells comes from the direct dependencies, making it hard to change lower-level modules without making large changes to the high-level modules.

Assume as an example that you have a high-level class, Product, that have a direct dependency to a low-level class, SqlDb. Now, changes to the low-level class will force the high-level class to be changed. And it may also be hard to re-use the high-level class due to this direct dependency.

How to implement

In order to invert the dependencies a set of service interfaces can be added, at the same level as the current module. These interfaces should then be implemented by the lower level module. See the diagrams.

In the traditional layering style there are direct dependencies from higher-level classes to lower level classes. This means that the top level classes will be dependent on changes on the lowest level. A change to the lowest level may propagate all the way up to the top forcing a complete recompile, re-test and re-deploy of all modules in the system.

If we add an abstract service interface at all layers that have dependencies to lower layers we effectively break this dependency chain. The high-level, mid-level, and low-level modules can be put into different assemblies (projects) so that a change in one layer does not affect any other layers as long as the interface isn’t changed.

Another aspect that is different from the traditional way of putting code into layers is that the abstract interfaces are grouped with the clients, and not together with their implementations. The interfaces should be designed from the clients needs and not the other way around. Changes to the interfaces should be driven from the clients, i.e. inverted compared to traditional layering.

Summary

This post ends the series on the SOLID principles. I started with an introduction to SOLID where I explained why you should care to learn what SOLID is and also introduced some code smells that is common in large software projects. I then went through the five different SOLID principles, The Single-Responsibility Principle, The Open/Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency-Inversion Principle and explained what they say, which code smells that may appear if not adhered to, and how to implement them.

I must remind you to take it easy and not add abstractions, apply patterns, and introduce these principles until you detect the smells. Doing that will add unnecessary complexity to your code, making it harder to work with and understand.

However, when you do introduce the principles, use all of them on the smelly part of the code. Now stop reading and write some code!

We are closing in on the final principle of SOLID. In the last post I wrote about the Liskov Substitution Principle, and now it is time to take a look at The Interface Segregation Principle (ISP).

Definition

The Interface Segregation Principle was coined by Robert C. Martin. It is explained in his book ”Agile Software Development Principles, Patterns, and Practices” from 2002 but has probably been around longer than that. It states that:

Clients should not be forced to depend on methods they do not use

The goal of it is to reduce the side effects and frequency of required changes by splitting the software into multiple, independent, parts.

Code Smells

As the code evolves and more features are added it is common that classes grow and more and more functionality is added to them. This has a tendency to grow into ”fat” interfaces, which can be identified by that their methods can broken up into groups, each group serving a different set of clients. The code will start to smell of:

• Needless complexity and needless redundancy – when interfaces grow you risk ”interface pollution”, i.e. interfaces that contain methods only needed by one or a few clients. Some implementations may not need all the methods of the interface but are forced to implement degenerated versions of the methods (methods that are empty or throws an exception when called). It may also be tempting to push empty implementations and exception throwing down to the base class, which leads to violations of LSP.
• Rigidity and Viscosity – A change to an interface, enforced by a single client, will force all other derivatives to be updated. Even though they do note require the functionality.

Fortunately there are some straight forward ways to fix these violations.

How to implement

In order to realize how to implement ISP you need to understand that clients of an object does not need to access it directly, they can instead access it through an abstract base class or a thin interface. In other words, split your fat interfaces into several thinner ones and serve each client the specific interface(s) they need. Let’s see an example, assume you have a class that looks like this:

public class ComplexClass
{
  // Methods called by clients in group A
  public void MethodA1() { ... }
  public void MethodA2() { ... }

  // Methods called by clients in group B
  public void MethodB1() { ... }
  public void MethodB2() { ... }
  public void MethodB3() { ... }

  // Methods called by clients in group C
  public void MethodC() { ... }
}

public class ClientInGroupA
{
  // Only calls methods MethodA1 and A2, but are dependent on the full interface
  private readonly ComplexClass _cc;
  public ClientInGroupA(ComplexClass cc)
  {
     _cc = cc;
  }
  ...
}

public class ClientInGroupB
{
  // Only calls methods MethodB1, B2, and B2, but are dependent on the full interface
  private readonly ComplexClass _cc;
  public ClientInGroupB(ComplexClass cc)
  {
    _cc = cc;
  }
  ...
}

public class ClientInGroupC
{
  // Only calls method MethodC, but are dependent on the full interface
  private readonly ComplexClass _cc;
  public ClientInGroupC(ComplexClass cc)
  {
    _cc = cc;
  }
  ...
}

Instead of handing all the clients the same interface, all public methods of an object of type ComplexClass. You can segregate the interface into three separate new interfaces, one for each group of clients:

public interface IGroupA
{
  void MethodA1();
  void MethodA2();
}

public interface IGroupB
{
  void MethodB1();
  void MethodB2();
  void MethodB3();
}

public interface IGroupC
{
  void MethodC();
}

public class ComplexClass() : IGroupA, IGroupB, IGroupC
{
  ...
}

public class ClientInGroupA
{
  // Only dependent on methods it uses
  private readonly IGroupA _oa;
  public ClientInGroupA(IGroupA oa)
  {
    _oa = oa;
  }
  ...
}

public class ClientInGroupB
{
  // Only dependent on methods it uses
  private readonly IGroupB _ob;
  public ClientInGroupB(IGroupB ob)
  {
    _ob = ob;
  }
  ...
}

public class ClientInGroupC
{
  // Only dependent on methods it uses
  private readonly IGroupC _oc;
  public ClientInGroupC(IGroupC oc)
  {
    _oc = oc;
  }
  ...
}

Summary

Applying the Interface Segregation Principle can help against code smells such as Needless Complexity, Needless Redundancy, Rigidity, and Viscosity. Even though it might not be possible to split up the implementation, it is possible to define thinner interfaces, streamlined towards the need of the clients.

Next up is the last part of SOLID, the Dependency Inversion Principle, which will help you design your interfaces in a way that is suitable for Object Oriented Design.

In the previous post I wrote about the O in SOLID, The Open/Closed Principle. Now it is time for the L, The Liskov Substitution Principle (LSP).

Definition

In the year 1988, the American Computer Scientist Barbara Liskov, wrote

What is wanted here is something like the following substitution property: If for each object o₁ of type S there is an object o₂ of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o₁ is substituted for o₂ then S is a subtype of T.

In other words this means that subtypes must be substitutable for their base types. An example of a violation of LSP would be: Given a method M(B) where B is an object of type BaseClass. If M(B) behaves badly given an object D of type DerivedFromBaseClass then D violates LSP.

Code Smells

Violation of LSP leads to Fragility. Parts of your code might break in subtle ways when adding new derived classes.

Attempts to fix this issues might lead to violations of OCP, which in turn introduces Rigidity and possibly also Immobility.

How to apply

Unlike the two previous principles, SRP and OCP, there are no named patterns to apply in order to fix violations of LSP. Manual inspection and unit testing comes a far way when it comes to detect violations and then you will need to determine from case to case how to fix the violation.

It can be tempting to put a test in the code to determine the type of the object passed to the method:

public void Method(Base b)
{
  // Do NOT do this. It violates OCP
  if (b is Derived d) { ... }
  else { ... }
}

These types of tests however violates OCP since it is no longer possible to add new derived types without changing existing code.

What can be done is, instead of adding type tests, you separate the violating methods from the existing interface. This will leave you with a common interface, that all classes can implement, and a specialized interface that contains the methods that one or more classes should not implement. For example, let’s assume that we have an interface, IF, that is implemented by the classes CA, CB, and CC. Now, assume CC conforms to LSP for methods MA, MB, and MC but violates LSP for methods MD and ME. You can then break out MA, MB and MC from IF and move them to a new interface IFCommon. You then let IF derive from IFCommon, let CA and CB still implement IF but let CC implement only IFCommon and it’s own versions of MD and ME. See the diagrams below:

Summary

The Liskov Substitution Principle puts tougher demands on derived classes than just the fact that they have a common base class. I demands that it should be possible to use the derived classes instead of the base classes, without breaking anything. Conformance to LSP is an enabler for OCP, since for it to be possible to extend the current behavior, by adding new derived classes, these must work as expected when used as their base class.

We are now more than half way through SOLID, next up is The Interface Segregation Principle.

In this third post on the SOLID principles we will look at the Open/Closed Principle (OCP).

Definition

Bertrand Mayer coined the Open/Closed Principle in 1988, and it states that ”A software entity (class, module, function) should be open for extension but closed for modification”.

A software entity complies to OCP if its behavior can be extended, and extending the behavior does not result in changes to it’s existing code.

Code smells

The most obvious code smell that appears for entities that does not follow OCP is Rigidity i.e. that the software is hard to change. A change to one entity results in a cascade of changes in other entities.

This also leads to Fragility, since being forced to make changes in many different entities makes it easy to break something. Your code base may also show signs of Immobility.

How to apply

NOTE: As I wrote in the previous posts, applying patterns and abstractions should be done only when smells are appearing. I recommend that you use the ”Fool me once” approach. That is, start with writing the code as if it is never going to change, then the first time you do need to change it, you apply the appropriate patterns and abstractions.

Your goal when applying OCP should be to make it easy to introduce changes by adding new code (open for extension), but not by modifying existing code that already works (closed for modification).

But how can that be done? The two statements sounds like contradictions. The answer, abstraction. There are two patterns that can be used to achieve this goal, and they both have the approach of splitting up concrete classes into abstract and concrete parts. The patters are The Template Pattern and The Strategy Pattern.

The Template Pattern

The Template Pattern uses inheritance to separate a generic algorithm from a detailed context. You apply it by splitting your current concrete class into two:

1. An abstract base class containing the generic code/algorithm, this is your template
2. The concrete context, that inherits from the abstract base class and implements the abstract methods

Applying this pattern opens up your code for extension by making it possible to add new behavior by adding new concrete classes that inherits from the abstract base class. You can do this without modifying the existing base class or any existing concrete classes.

The Strategy Pattern

The Strategy Pattern is also used to separate a generic algorithm from a detailed context. Unlike the Template Pattern it does so by delegation and not inheritance.

To apply the Strategy Pattern you split up your concrete implementation into three parts:

1. A concrete class containing the generic algorithm
2. An interface that abstracts the detailed context
3. A concrete strategy class that implements the interface

To use these classes you first instantiate the strategy class (3) and hand it to the class containing the generic algorithm (1), preferably by constructor injection.

This opens up your code for extension by allowing you to add new strategies (3) without having to modify any of the existing code. The generic algorithm can also be re-used by given different strategies.

Summary

The Open/Closed Principle is the second of the five principles of SOLID. It can be a bit hard to understand what it means that something is ”open for extension but closed for modification”, hopefully this post has made it a bit clearer. I advise you to read up a bit more on both the template, and the strategy, pattern.

Next, we will dive into the third principle of SOLID, The Liskov Substitution Principle.

You are now reading the second part of my blog series on the SOLID principles. In the first post I introduced the concept and gave some reasons to why you should learn about SOLID. In this part I will write about the first of the five SOLID principles, the Single-Responsibility Principle (SRP).

Definition

The Single-Responsibility Principle states that ”A class should have only one responsibility” or ”A class should have only one reason to change”.

This means that, if you need to change a class for more than one reason, it has multiple responsibilities, and therefore violates SRP.

Code smells

There are a couple of different code smells that might appear due to violation of SRP. These are:

• Fragility – If a class has more than one responsibility, classes that should not be related becomes coupled. Changes related to one of the responsibilities may break the application in unexpected ways.
• Rigidity – Changes related to one responsibility may force classes depending on other responsibilities to be re-compiled / re-deployed, making the application harder to change.

How to apply

NOTE: It is not wise to apply SRP, or any other principle for that matter, if there is no symptom! Only once you have identified that there are changes being made and it is troublesome, then it should be fixed.

The most obvious way to apply SRP is to separate implementation of the identified responsibilities into different classes. This might however not be possible due to details of the hardware or the operating system. There are however a few patterns that can help. Though not all of them may apply to your specific implementation, I will list them here for you and you should be able to decide if it is good fit for you.

The Facade Pattern

The Facade Pattern is used when you want to provide a simple and specific interface onto a group of objects that have a complex and general interface.

Assume that it is not possible to split up the implementation, so you are stuck with a complex, multi responsibility object. You can then create simple interfaces each cover a single responsibility of the implementation. Users then only have to care about the methods of that specific interface.

Data Access Object

In the case where business logic and persistence functionality have been mixed into a single class (for example if you have a Product class with it’s data fields that also knows how to read and write to the database) the responsibility of database access can be moved to a Data Access Object (DAO).

To implement this you create an interface for CRUD operations towards the database, for the specific business logic. Then you create a separate implementation, removing the persistence logic/responsibility from the business logic class.

The Proxy Pattern

The Proxy Pattern is another way to separate, for example, persistence logic from business logic. Proxies are not trivial to implement but provide good separation. I recommend that you do read up on the proxy pattern, and the other patterns as well, from different sources and look at a few examples before implementing it in your own code.

Assume again that you have business logic and database logic mixed in the same class. In short, the proxy pattern is implemented by breaking up the current implementation into three parts:

1. An interface
2. Business logic
3. Database aware logic

Both the business logic and the database aware logic will implement the interface. The database logic will be aware of the business logic class and have the responsibility of accessing the database. The business logic will now however have no dependency to the database.

The database aware logic will work as a proxy for the business logic. Users can be handed and use the proxy, and since the interface is the same as for the business logic, they can treat it as a normal business logic object, happily unaware of that it accesses the database under the surface.

Summary

The Single-Responsibility Principle is easy to understand, but hard to get right. The reason being we naturally group responsibilities together.

After reading this post you hopefully have some ideas what to look out for and how to tackle the issues. I am also quite certain that you will need to read a bit more, see some code examples, and work a bit with your code before you start feeling comfortable with applying SRP.

In the next post we will be looking into the next principle of SOLID, the Open/Closed Principle (OCP).

If you have been working with object oriented programming (OOP) for some time you have probably heard of the SOLID principles. There is a lot of information available online on SOLID, of various quality. In this blog series, where you are currently reading the first part, I will cover the principles in detail and explain them in a way that hopefully makes sense to most developers.

Benefits

The first question we should answer is the why. Why should you put time and effort into learning about SOLID?

To answer this question we must first recognize that code that is worked on without any clear structure or rules will grow into an unmaintainable nightmare over time, it will rot. Adding or changing features becomes harder and harder and requires an increasing amount of time and effort. Finally a decision is usually made to start over and re-write large portions of the application. Then the whole process starts over.

More detailed, the symptoms of poor design are:

• Rigidity – It is difficult to make changes to the source code
• Fragility – It is easy to break the application when making changes
  
• Immobility – It is hard to re-use portions of the code
• Viscosity – It is easier to make ”hacky” changes than following the intended design
• Needless complexity – The code is littered with unnecessary constructs that makes the code complex and difficult to understand
• Needless repetitions – The code contains a lot of code blocks that are just copy/paste, maybe with some smaller modifications
  
• Opacity – The code is difficult to understand
  

If you can accept that, with changing requirements and changes to the code to address these changes, over time the code will start to show one or more of the symptoms listed above. Then you can also accept that some sort of strategy or set of rules needs to be applied to address these symptoms. This is where SOLID comes in. The goal of the SOLID principles is to make your code easier to develop, understand, maintain, and expand. And to keep it that way in the long run. Sounds like a nice goal doesn’t it?

Taking action

It is important to understand that principles are applied in order to solve symptoms of poor design. They are not applied all over the system just because someone told us it would be a good thing to do. Over-conformance to the principles leads to needless complexity. Understand why you do things a certain way and when it is a good time to do it!

When introducing new functionality or making changes to existing code a good approach is to try to introduce the simplest thing that could possibly work. Avoid trying to think ahead too much and adding complexity in an attempt to future proof the code for requirement changes that might come sometime in the future.

Then, when you realize that you do have, or are about to introduce, a code smell, then it is the time to take action. Do not let code smells accumulate and believe you can fix them later. When you have identified a smell, take action immediately.

1. Identify the problem
   
2. Diagnose the problem by applying design principles
3. Solve the problem by applying an appropriate design pattern
   

Brief history

The theory of the SOLID principles were introduced by Robert C. Martin in his 2000 paper Design Principles and Design Patterns but the acronym was introduced by Michael Feathers later. Martin did however not come up with all the principles himself but rather collected them and introduced them as a set of principles that has great benefits when combined.

The five different principles that makes up SOLID are:

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

Conclusion

Code that is being developed without certain principles and strategies will start to rot, introducing code smells that will grow bigger and more severe over time. The SOLID principles helps diagnosing these code smells and adhering to them will help to keep the code in a maintainable state over time.

Next post will be on the first principle of SOLID, the Single Responsibility Principle, SRP.