Solid Summary

SRP states there should be one reason for a module to change. Stakeholders are usually the reason to changes. The principle is voilated if change in one module affects code other stakeholders depend upon.

The core of a good software is any extension should only cause small changes. This could be acheived by organizing the dependencies and ensuring changes to one component does not affect others.

The dependencies are unidirectional creating a notion of layers or levels. Modules at the higher level are protected from changes introduced at the lower level.

A program's behaviour is unchanged when an object of type T is replaced with object of type S, where S is a subtype of T. Voilations:

1. A duck is replaced by a rubber duck.
2. A rectangle is replaced with square. Calculation of square of different from that of reactangle.

A type should not depend on behaviours it doesn't use. A class `Employee` depends on a framework F, F in turn depends on X. Some feature of the X is not used. If the unused feature breaks which would inturn break F and Employee.

Fleixble system should depend on abstraction instead of concretion. But dependeing upon concrete dependencies are inevitable. For example, the OS is usually a stable dependency. We are worries about dependencies that are volatile, which are under