This document discusses principles of object-oriented design and poor design symptoms. It covers rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity as symptoms of poor design. It then discusses refactoring, coupling, cohesion, and the SOLID principles - single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion principles. Design goals are flexibility, understandability, and reusability through high cohesion and loose coupling using abstraction and separation of concerns.

1. THINKING IN OBJECT-
ORIENTED
Sadad PSP, IT Dept
Winter-Spring 2019

2. SYMPTOMS OF ROTTING(POOR)
DESIGN
The design is hard to change.
The design is easy to break.
The design is hard to reuse.
It is hard to do the right thing.
Overdesign.
Mouse abuse.
Disorganized expression.

3. RIGIDITY
THE DESIGN IS HARD TO CHANGE
The system is hard to change because every change forces many
other changes to other parts of the system.

4. FRAGILITY
THE DESIGN IS EASY TO BREAK
Changes cause the system to break in places that have no conceptual
relationship to the part that was changed

5. IMMOBILITY
THE DESIGN IS HARD TO REUSE
It is hard to disentangle the system into components that can be
reused in other systems

6. VISCOSITY
IT IS HARD TO DO THE RIGHT THING
Doing things right is harder than doing things wrong. A viscous
project is a project in which the design of the software is hard to
preserve
viscosity of the software
viscosity of the environment

7. NEEDLESS COMPLEXITY
OVERDESIGN
The design contains infrastructure that adds no direct benefit

8. NEEDLESS REPETITION
MOUSE ABUSE
The design contains repeating structures that could be unified under
a single abstraction.

9. OPACITY
DISORGANIZED EXPRESSION
It is hard to read and understand. It does not express its intent well

10. REFACTORING
The process of changing a software system in such a way that it does
not alter the external behavior of the code yet improves its internal
structure. [Fowler]

11. NOTE: COUPLING
is a measure of how strongly one element is connected to,
has knowledge of or relies on other elements. A class with high (or
strong) coupling suffers from:
Changes in related classes force local changes.
Harder to understand in isolation.
Harder to reuse because its use requires the additional presence of
the classes on which it is dependent.

12. NOTE: COHESION
(or more specifically, functional cohesion) is a measure of
how strongly related and focused the responsibilities of an element
are. A class with low cohesion suffers from:
hard to comprehend
hard to reuse
hard to maintain
delicate; constantly effected by change

13. S.O.L.I.D
Single responsibility principle (SRP)
Open Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

14. SRP: THE SINGLE-RESPONSIBILITY
PRINCIPLE
A class should have only one reason to change
It give you high cohesion
It’s often hard to identify different responsibilities

15. SRP PROBLEM EXAMPLE
Two responsibility:
Data management
Data presentation

16. SRP SOLUTION EXAMPLE
Tow responsibility:
Data management
Data representation

17. OCP: THE OPEN–CLOSED
PRINCIPLE
Software entities (classes, modules, functions, etc.) should be open
for extension, but closed for modification.
You should be able to extend the behavior of a module without
changing it
Abstraction is the key

18. LSP: THE LISKOV SUBSTITUTION
PRINCIPLE
Subtypes must be substitutable for their base types

19. ISP: THE INTERFACE-
SEGREGATION PRINCIPLE
Clients should not be forced to depend upon the interfaces that they
do not use.

20. DIP: THE DEPENDENCY-INVERSION
PRINCIPLE
High-level modules should not depend on low-level modules. Both should
depend on abstractions.
Abstractions should not depend on details. Details should depend on
abstractions