SOLID Software Design Principles

Thu 28 April 2022

SOLID

[S]ingle-responsibility principle:

Every class should only have one responsibility.

[O]pen-closed principle:

Software entitities (e.g. classes, functions, components), should be open for extension, but closed for modification. Write code in a manner that you are able to add new functionality, without changing the existing code, this prevents situations where a change to one class or function, requires you to modify all parts of the code that make use of this class or function.

[L]iskov substitution principle:

Objects of a parent class shall be replaceable with instances of its children, without breaking the application, i.e. functions that use ponters or references to a base class, must be able to use objects of the derived class without knowing it (extends the "open-closed principle", focusses on the behaviour of a parent class and its children).

[I]nterface segregation principle:

Many client-specific interfaces are better than one general-purpose interface. Clients should not be forced to depend upon interfaces that they do not use.

[D]ependency inversion principle:

High-level modules which provide complex logic, should be easily reusable and unaffected by changes in low-level modules which provide complex logic (e.g. a 'core' module).

To achieve this you need to provide an abstraction which decouples the high-level and low-level modules from each other, by applying the following rules:

  • 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.

An important detail of this definition is, that high-level and low-level modules depend on the abstraction. The design principle does not just change the direction of the dependency, as you might have expected when you read its name for the first time. It splits the dependency between the high-level and low-level modules by introducing an abstraction between them. So in the end, you get two dependencies:

  • the high-level module depends on the abstraction, and
  • the low-level depends on the same abstraction.

Category: Standards