WEEk 04 - L.I.D. (Chapters 9, 10, and, 11)

Liskov Substitution Principle

LSP is primarily about guiding the use of inheritance.
Every "subtype" should be able to be used as its parent type "all the way up the chain"
In the first image this is done well

the example in the book is long and convoluted
suffice it to say a simple violation of subsitutibility can cause a system's architecture to baloon out of control.

Picture of the BAD way:

Better: add more interfaces!!

In general it is considered harmful to depend on code taht you don't actually use.
In development time it can cause unnecessary recompilations and redeployments.
- Great example: windows nano server
- example of "old server" system just for the image
- content of this example to be discussed live in the show. Stay tuned for incoming youtube link after tomorrow night.... or in theory it is already there and I never removed this line of text. That souds like me.
Something that carries baggage that you don't need can cause you troubles that you didn't expect.

the most flexible systems are those where source code dependencies only refer to abstractions
never depend on CONCRETE classes, instead always write an interface layer whan consuming something
good software designers and work hard to reduce the volatility of interfaces
- example: instead of calling a database's SAVE method directly if you call it through an interface you can later swap out your database by editing the ONE file that makes calls to the concrete classes.
Stable software architectures are those that avoid depending on volitile concretions

Don't refer to volatile concrete classes
Don't derive from volatile concrete classes
Don't override concrete functions
Never mention the name of anything concrete and volatile
The key to the DIP is to ensure that all dependencies point in one direction across the boundry line
note that the orange dotted lines