L4 Solid Principles Flashcards
What are the SOLID Principles
Introduced in the early 2000s by Robert C. Martin
Tells us how to arrange our functions and data structure into classes and how those classes should interconnect
Principles are:
- Single Responsibility Principle (SRP)
- Open - Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
What does it mean to implement Single Responsibility Principle
A class should have only one responsibility
What does it mean to implement the Open-Closed Principle
Classes should be open for extension but closed for modification
● Modifying a class increases risk of breaking already working code
● To make our calculator extensible, we need to make it more generic using interfaces
● Following OCP we can now add any new operation without changing ANY class
What is the Liskov Substitution Principle
● Barbara Liskov: “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 behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T”
The Liskov Substitution Principle (LSP) is a fundamental principle of object-oriented programming that states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program. In simpler terms, if you have a class A and a subclass B, you should be able to use B wherever you can use A without causing any problems.
● Definition is quite verbose, so the classical square/rectangle problem:
● Where is the problem?
○ LSP says that User should be able to use Rectangle and
Square in the same way, but…
○ Square has the same height and width - calling
setHeight(10) and setWidth(10) is possible, but is waiting for
a disaster
○ So we introduce setSide(double) which in its body calls setHeight() and setWidth() with the
same parameter
○ LSP is broken, as User has to treat Rectangle and Square differently!
○ In other words, Square cannot be substituted wherever Rectangle shows up
● So, is Square a Rectangle?
○ Almost always no!
● LSP is a nice reminder that what is an “is-a” relationship in the “real world” is
not necessarily an “is-a” relationship in OOP world
What is Interface Segregation Principle
● A client should not depend on methods they do not use
● Let’s say Client 1 only uses op1(), Client 2 uses op2() and Client 3 uses op3()
● Client 1 depends on op2 and op3 even though it doesn’t call them
● If op2() or op3() change, Client 1 will still need to recompile and be redeployed into production
What is Dependency Inversion Principle
High-level modules or classes should not depend on low-level modules or classes, but both should depend on abstractions. In other words, the principle suggests that it’s better to depend on abstract interfaces or classes rather than concrete implementations
What is coupling and what is decoupling?
Coupling refers to the degree to which different modules or components in a system rely on each other.
Decoupling is the process of reducing coupling between different parts of a program. This can be achieved by breaking down a program into smaller, more modular components, each with well-defined interfaces that minimize dependencies between modules.
Flow of control and source dependency
● Any computer program will have a procedure function call tree, e.g
Why does architecture matter?
● High level policy depends on low level details
○ HL1() breaks if LL1() breaks
● Compile dependencies
○ Small change in LL1() forces everyone up the tree to recompile!
● How can we structure software better?
- SOLID principles
SRP friendly Employee
● A good general solution is to separate code that supports different actors (i.e. decouple)
● For our Employee, most solutions will require moving the methods into different classes
Interface Segregation Principle
Solution
● Alternative solution is to depend only on what we use
● Notice that OPS didn’t change
○ However, change to op1() doesn’t cause clients to
recompile
● Once again interfaces to the rescue
○ With interfaces we inverted source code dependencies
(OPS is pointing towards the interfaces), but the flow
of control remained the same (from Clients to OPS)
● In general, do not depend on something that
carries baggage that you don’t need
Interface Segregation Principle (ISP)
Effect of ISP
ISP has inverted source code dependency (many OOP design
techniques rely on this trick!)
Dependency Inversion Principle (DIP)
Rule of Thumb
○ Don’t refer to volatile concrete classes (i.e. classes that change very often)
○ Don’t inherit from volatile concrete classes
○ Don’t override concrete functions
○ Avoid mentioning the name of anything concrete and volatile
Dependency Inversion Principle (DIP)
Problem
Dependency Inversion Principle (DIP)
Solutions
● Each time the requirement changes, we need to modify Person
● But, by programming to an interface, we can avoid changing the Person!
● Person can now save into any database which satisfies the Database interface!
