Dependency Injection Principle

This is that last part of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Dependency Inversion Principle.

The Dependency Injection Principle (DIP): High level modules should not depend upon low level modules. Both should depend upon abstractions.

Imagine a world without plugs and sockets. The computer is directly soldered into an electrical wire in the wall. Whenever you buy a motherboard you also get a mouse, keyboard and monitor, but they're all directly soldered onto the motherboard by the manufacturer. Everything works fine, but things get complicated when you want to remove or replace anything. If you try to replace the mouse:

• You risk damaging the motherboard
• It takes forever to solder
• Soldering is error prone because the new mouse has different wires

A world without plugs and sockets sounds ridiculous. Yet we programmers have a tendency to pull out the metaphorical soldering iron and hard-wire our classes together as we're making them. If the classes are hard-wired together, and you want to replace one of them:

• You risk damaging code that uses the class
• It takes forever to find and change every place that the class is used
• Inserting the replacement class is error prone because it is slightly different to the old class

The Dependency Injection Principle is basically a way of adding plugs and sockets to your code. It allows you to create your high level modules (the computer) independent of the low level modules (the mouse). The low level modules can be created later, and are easily replaceable.

Interface Segregation Principle

This is part four of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Interface Segregation Principle.

The Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use.

The "fat interfaces" — interfaces with additional useless methods — lead to inadvertent coupling between classes. This is the real reason why the ISP should be adhered to. Coupling is the bane of reusability. Fat interfaces also introduce unnecessary complexity, which isn't good for maintainability or robustness.

Liskov Substitution Principle

This is part three of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Liskov Substitution Principle.

The Liskov Substitution Principle (LSP): functions that use pointers to base classes must be able to use objects of derived classes without knowing it.

Subtype Requirement:

Let ${\displaystyle \phi (x)}$ be a property provable about objects ${\displaystyle x}$ of type T. Then ${\displaystyle \phi (y)}$ should be true for objects ${\displaystyle y}$ of type S where S is a subtype of T.  

When first learning about object oriented programming, inheritance is usually described as an "is a" relationship. If a penguin "is a" bird, then the Penguin class should inherit from the Bird class. The "is a" technique of determining inheritance relationships is simple and useful, but occasionally results in bad use of inheritance.

The Liskov Substitution Principle is a way of ensuring that inheritance is used correctly.

Open Closed Principle

This is part two of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Open Closed Principle.

The Open Closed Principle (OCP): You should be able to extend a classes behavior, without modifying it.

The OCP is sometimes alternatively defined as:

A class should be open to extension, but closed to modification.

Robert Martin sums up the rationale for the OCP like this:

"When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with 'bad' design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works." — Robert Martin

The Benefits

As stated by Robert Martin, classes that must be modified to accommodate new changes are fragile, rigid, unpredictable and unreusable. By insulating the class from changes, the class becomes robust, flexible, and reusable. Also as no modifications are made to the code no bugs can be introduced, leading to code that only becomes more stable over time through testing. The ability to reuse a class that has been working for years without modification is clearly preferable to modifying the class every time requirements change.

Single Responsibility Principle

This is part one of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Single Responsibility Principle.

The Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.

The SRP is roughly the same as having "high cohesion". A class is said to have high cohesion if it's behaviours are highly related, and strongly focused. The SRP states that a class should be cohesive to the point that it has a single responsibility, where a responsibility is defined as "a reason for change."

The Benefits

• The class is easier to understand
  When the class only does "one thing", its interface usually has a small number of methods that are fairly self explanatory. It should also have a small number of member variables (less than seven-ish).
• The class is easier to maintain
  Changes are isolated, reducing the chance of breaking other unrelated areas of the software. As programming errors are inversely proportional to complexity, being easier to understand makes the code less prone to bugs.
• The class is more reusable
  If a class has multiple responsibilities, and only one of those is needed in another area of the software, then the other unnecessary responsibilities hinder reusability. Having a single responsibility means the class should be reusable without modification.