1. Liskov Substitution Principle Jon McBee CLA, CLED, CTD, CPI, LabVIEW Champion

2. Liskov Substitution Principle (LSP) If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

3. Liskov Substitution Principle S is not a valid subtype of T if the behavior of P changes when T is replaced with S “Functions that use base classes must be able to use objects of derived classes without knowing it” – Robert C. Martin

4. Analogy

5. DC Device 5mm AC Adapter Interface +5mm Adapter Panasonic +2V +5A +Positive Polarity Sony +5V +2A +Positive Polarity Samsung +100V +0.1A +Negative Polarity

6. Analogy Functions that use base classes must be able to use objects of derived classes without knowing it

7. Liskov Substitution Principle +2V +5A +5V +2A +100V +0.1A S is not a valid subtype of T if the behavior of P changes when T is replaced with S DC Device 5mm AC Adapter Interface +5mm Adapter Panasonic +2V +5A +Positive Polarity Sony +5V +2A +Positive Polarity Samsung +100V +0.1A +Negative Polarity S T P

8. Dependency Inversion Principle: Part B +2V +5A +5V +2A +100V +0.1A DC Device 5mm AC Adapter Interface +5mm Adapter Panasonic +2V +5A +Positive Polarity Sony +5V +2A +Positive Polarity Samsung +100V +0.1A +Negative Polarity

9. Liskov Substitution Principle = =

10.  LSP violations impact the flexibility of our software  LSP violations are difficult to predict  LSP violations should be detectable with unit testing

11. LSP in the Wild

12. Caraya  A new take on unit testing by JKI  Turn your sandbox code into unit test code  Unit test your code without interrupting your workflow  On Github: https://github.com/JKISoftware/Caraya

13. Summary  A function that depends on an abstract class as a source code dependency must be able to use a child of that abstraction as a run time dependency without knowing it  LSP effects both the function calling the abstraction, and the child classes implementing the abstraction  Any code using an abstraction must assume nothing else beyond the defined abstraction  Any implementation of an abstraction must adhere to the requirements and conventions of the interface to the abstraction  LSP violations are easier to avoid when following DIP part B  Abstractions should not depend on details, details should depend on abstractions  The high level module should define the interface, not the details  The compiler won’t show you LSP violations  LSP violations are hard to foresee when writing code, but can be detected with unit testing