Solid Principles

Content
1. Summary

2. Details

Summary
SOLID principles - reduces coupling but facilitate changes

S - Separates concerns

O - Simplify addition/extension

L - Writing good abstractions

I - Minimise the dependencies of interfaces

D - Use abstractions for dependencies

Details
Single Responsibilities Principle [SRP]

Everything should do just one thing - Common knowledge

Orthogonality - Need to design components that are self-contained:

independent, single well-defined purpose [cohesion].

We should be able to change one thing without worrying about another ie, we
shall be to change things in isolation.

A question to be asked, When would this code change?

Prefer cohesive software entities. Everything that does not strictly belong
together, should be separated.

Open Closed Principle [OCP]

Solid Principles 1
 While adding new functionality (code), there should not be any need to change
the old code.

The type-based programming is unmaintainable.

copy() - function works with any type.

Prefer software design that allows the addition of types or operations without
the need to modify existing code.

Liskov Substitution Principle [LSP]

Deals with type-based things

O1 [S] and O2 [T ] Let be the object [type]

In Program P , if O1 [S] is replaced by O2 [T ] and P behaviour is unchanged
⇒ T is a subtype of S
Subtype must be substitutable for their bare types

Behaviour subtyping [aka IS A relationship]

Contravariance of method arguments in a subtype. Derived → Generic

Covariance of return types in a subtype. Generic → Derived

Preconditions cannot be strengthened in a subtype

Postconditions cannot be weakened in a subtype

Invariant of the supertype must be preserved in a subtype [Eg: Import

module]

Squares and Rectangles are related in maths, but not necessarily in Computer
Science, well again depends on the context.

Eg: copy() works for any type

Make sure that inheritance is about behaviour [function] behaviour not about
data.

Make sure that the contract of base types is adhered to.

Make sure to adhere to required to the concept. - templated code

Interface Segregation Principle [ISP]

Solid Principles 2
 Many specifics are better than one general interface mixins - Dependency
Injection

We have a tendency to group in class the things that are named similarly -
Which violates ISP

For every new type, write a specific interface

Eg: copy()

Make sure interfaces don't induce unnecessary dependencies.

Dependency Inversion Principle [DIP]

Deals with types

Should Depends on : →

High level [caller] → Abstractions [low level abstraction]

Low level [called] → Abstractions

Details → Abstractions

MVC pattern

Eg: copy()

Prefer to depend on abstractions (ie, classes or concepts) instead of concrete

types

References
Breaking Dependencies: The SOLID Principles - YouTube

Variance in programming languages – rubber duck typing (rubber-duck-typing.com)

Solid Principles 3