The document discusses principles of software design, focusing on the Single Responsibility Principle (SRP), Open/Closed Principle (OCP), and Liskov Substitution Principle (LSP). It highlights the importance of separating concerns in classes and modules to avoid issues related to changes affecting multiple parts of a system. Additionally, it emphasizes creating fine-grained interfaces tailored to client needs to enhance flexibility and reusability.

1. KeyShowR
Explore Experience Empower
food on a child who's not hungry
Don't push

2. It is hard to change because every change affects too many other parts of the system.
When you make a change, unexpected parts of the system break
It is hard to reuse in another application because it cannot be disentangled from the
current application
costtotal = costdevelop + costmaintain
costmaintain = costunderstand + costchange + costtest + costdeploy
Implementation Patterns - Kent

3. THE R P
“ THERE SHOULD NEVER BE MORE THAN ONE
REASON
FOR A CLASS TO CHANGE “
”States that every class should have a single responsibility,
and that responsibility should be entirely encapsulated by the class
All its services should be narrowly aligned with that responsibility.”
If a class assumes more than one responsibility,
then there will be more than one reason for it to change
family of functions that serve one particular

4. SRP PROBLEM
STATEMENT

5. SRP VIOLATION: SYMPTOMS
 Unrelated functions in the same class
 SQL and HTML in the same module
 Business rules in JSPs
 Business logic is Framework aware
 UI code knows about DB/Business logic
 FAT classes
 Class name having phrase like “Manager/Utils”

6. SRP

7. FIX SRP VIOLATION
 Separate functions that change for different
reason to a different module/class
 Create boundaries between DB/UI/Business rules
 Identify families of functions and move them to
new classes
 Move business logic from framework classes to
new modules , use delegate pattern
 ??

8. THE CP
‘SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)
SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR
MODIFICATION.’
“ says that you should design modules that never change.
when requirements change, you extend the behavior of such modules
by adding new code, not by changing old code that already works”
The primary mechanisms behind the OCP
are abstraction and polymorphism

9. OCP PROBLEM
STATEMENT

10. OVER ENGINEERED OCP

11. THE SP
“ FUNCTIONS THAT USE POINTERS OR
REFERENCES
TO BASE CLASSES MUST BE ABLE TO USE
OBJECTS
OF DERIVED CLASSES WITHOUT KNOWING IT “
If there is a function which does not conform to the LSP, then that function uses a
pointer
or reference to a base class, but must Know about all the derivatives of that base class
Lsp example:
void DrawShape(Shape s)
{
if (s instanceof Square)
s.DrawSquare( );
else if (s instanceof Circle)
s.DrawCircle();
}
refused-bequest

12. LSP VIOLATION: SYMPTOMS
 Derived class throws some exception that the
base class users don’t expect.
 Derived class having do-nothing(){} functions.
 Methods throwing exceptions unconditionally.
 Classes having TYPE checking code.
 Base class having dependency to derived classes.
 ??

13. FIX LSP VIOLATION
 Apply ISP
 Break the IS A relation (representatives don’t
share the relations ships of the things they
represent )
 ??

14. LSP PROBLEM STATEMENT

15. THE SP
States CLIENTS SHOULD NOT BE FORCED
TO DEPEND UPON INTERFACES
THAT THEY DO NOT USE
Make fine grained interfaces that are client specific.

16. THE IP
It is hard to change because every change affects too many other parts of the system.
When you make a change, unexpected parts of the system break
It is hard to reuse in another application because it cannot be disentangled from the current application
“ States that modules that encapsulate high
level policy should not depend upon
modules that implement details.”

17. CAN YOU PLAY MY GAME ?
Duncan Fletcher