12/13/19

1 2

Review: Design levels

Architectures/Framework
ITSS SOFTWARE DEVELOPMENT (Financial System, J2EE,…)
11. DESIGN PRINCIPLES OOD Patterns

Nguyen Thi Thu Trang OOD Principles

[email protected]
Specific Data Structures
Algorithmic Approaches

General + OO Concepts

1 2

S.O.L.I.D Principles of OOD Content

• SRP: The Single Responsibility Principle 1. S: The Single Responsibility Principle
• OCP: The Open Closed Principle 2. O: The Open Closed Principle
• LSP: The Liskov Substitution Principle 3. L: The Liskov Substitution Principle
• ISP: The Interface Segregation Principle 4. I: The Interface Segregation Principle
• DIP: The Dependency Inversion Principle 5. D: The Dependency Inversion Principle
6. Case study: Reminder program

3 4

1
 12/13/19

Principles of OO Class Design Principles of OO Class Design

SRP: The Single Responsibility Principle SRP: The Single Responsibility Principle (cont)
• Two applications are using this Rectangle class:
“There should never be more than one reason • Computational Geometry Application uses this class to
for a class to change” calculate the Area
• Graphical Application uses this class to draw a
Or Rectangle in the UI

“A class should have one, and only one type of

responsibility.”

5 6

Principles of OO Class Design Principles of OO Class Design

SRP: The Single Responsibility Principle (cont) SRP: The Single Responsibility Principle (cont)
• What is a Responsibility?
q A better design is to separate the two responsibilities • A reason for change
into two completely different classes
• “Modem” sample
• dial & hangup functions for managing connection
• send & recv functions for data communication

è Should separate into 2 repositories!

q Why is it important to separate these two

responsibilities into separate classes?
7 8

2
 12/13/19

Principles of OO Class Design

Content OCP: The Open Closed Principle
1. S: The Single Responsibility Principle “Software entities(classes, modules, functions, etc.) should
be open for extension, but closed for modification.”
2. O: The Open Closed Principle Bertrand Meyer, 1988
3. L: The Liskov Substitution Principle Or
“You should be able to extend a classes behavior, without
4. I: The Interface Segregation Principle modifying code”
• “Open for Extension”
5. D: The Dependency Inversion Principle • The behavior of the module/class can be extended
6. Case study: Reminder program • The module behave in new and different ways as the requirements
changes, or to meet the needs of new aplications
• “Closed for Modification”
• The source code of such a module is inviolate
• No one is allowed to make source code changes to it

9 10

Principles of OO Class Design Principles of OO Class Design

OCP: The Open Closed Principle (cont) OCP: The Open Closed Principle (cont)
• Client & Supplier classes are concrete • Change to support Open-Closed Principle.
è Abstraction is the key.
• If the Supplier implementation/class is changed, Abstract
Client also needs change. Supplier
è How to resolve this problem?
• The Concrete Supplier class implements the
Abstract Supplier class / Supplier Interface.
• The Supplier implementation is changed,
• the Client is likely not to require any change. Supplier
Supplier
è The Abstract Supplier class here is closed for
modification and the Concrete class implementations here
are Open for extension.
21

11 12

3
 12/13/19

Principles of OO Class Design

Content LSP: The Liskov Substitution Principle
1. S: The Single Responsibility Principle • “Functions that use pointers or references to base classes must
be able to use objects of derived classes without knowing it.”
2. O: The Open Closed Principle • Or
3. L: The Liskov Substitution Principle “Subclasses should be substitutable for their
4. I: The Interface Segregation Principle base classes.”
5. D: The Dependency Inversion Principle
6. Case study: Reminder program

22

13 14

Principles of OO Class Design Principles of OO Class Design

LSP: The Liskov Substitution Principle (cont) LSP: The Liskov Substitution Principle (cont)
• Ostrich is a Bird (definitely!!!) • “Inheritance” ~ "is a” relationship
Bird
• Can it fly? No! => Violates the LSP • But, easy to get carried away and end up in wrong design
èEven if in real world this seems with bad inheritance.
natural, in the class design, Ostrich è The LSP is a way of ensuring that inheritance is used
should not inherit the Bird class + fly() correctly
èThere should be a separate class • Why The LSP is so important? If not LSP,
for birds that can’t really fly and • Class hierarchy would be a mess and if subclass instance
Ostrich inherits that. was passed as parameter to methods method, strange
behavior might occur.
• Unit tests for the Base classes would never succeed for the
KingFisher Ostrich
subclass.
è LSP is just an extension of Open-Close Principle!!!

15 16

4
 12/13/19

Principles of OO Class Design

Content ISP: The Interface Segregation Principle
1. S: The Single Responsibility Principle • “Client should not be forced to depend upon
2. O: The Open Closed Principle interface that they do not use.”
3. L: The Liskov Substitution Principle • Or
• “Many client specific interfaces are better than one
4. I: The Interface Segregation Principle
general purpose interface.”
5. D: The Dependency Inversion Principle
6. Case study: Reminder program

17 18

19 20

Principles of OO Class Design Principles of OO Class Design

ISP: The Interface Segregation Principle ISP: The Interface Segregation Principle (cont.)
• Interfaces with too many methods are less re-usable.
{Applying ISP} • Such "fat interfaces“ with additional useless methods lead
to inadvertent coupling between classes.
• Doing this also introduce unnecessary complexity and
reduces maintainability or robustness in the system.

è The ISP ensures that, Interfaces are developed so that,

each of them have their own responsibility and thus they
are re-usable.

19 20

5
 12/13/19

Principles of OO Class Design

Content DIP: The Dependency Inversion Principle
1. S: The Single Responsibility Principle “High level modules should not depend upon
2. O: The Open Closed Principle low level modules. Both should depend upon
3. L: The Liskov Substitution Principle abstractions”
4. I: The Interface Segregation Principle Or
5. D: The Dependency Inversion Principle “Abstractions should not depend upon details.
Details should depend upon abstraction.”
6. Case study: Reminder program
Or
“Depend upon Abstractions. Do not depend
upon concretions.”

21 22

Principles of OO Class Design

DIP: The Dependency Inversion Principle Content
• Strategy of depending upon interfaces or abstract 1. S: The Single Responsibility Principle
functions and classes, rather than upon concrete
functions and classes. 2. O: The Open Closed Principle
A well designed object-oriented application.
•
• E.g. Layers of application
3. L: The Liskov Substitution Principle
4. I: The Interface Segregation Principle
5. D: The Dependency Inversion Principle
6. Case study: Reminder program

23 24

6
 12/13/19

25 26

Design exercise TimeToStretch suggests exercises

• Write a typing break reminder program public class TimeToStretch {
• Offer the hard-working user occasional reminders of the public void run() {
health issues, and encourage the user to take a break System.out.println("Stop typing!");
from typing suggestExercise();
• Naive design }
• Make a method to display messages and offer public void suggestExercise() {
exercises ...
• Make a loop to call that method from time to time }
(Let's ignore multi-threaded solutions for this }
discussion)

25 26

27 28

Timer calls run() periodically Main class puts it together

public class Timer { class Main {
private TimeToStretch tts = new TimeToStretch();
public static void main(String[] args) {
public void start() {
Timer t = new Timer();
while (true) {
... t.start();
if (enoughTimeHasPassed) { }
tts.run(); }
}
...
}
}
}

27 28

7
 12/13/19

29 30

Module dependency diagram Decoupling

• An arrow in a module dependency diagram indicates • Timer needs to call the run method
“depends on” or “knows about” – simplistically, “any • Timer doesn't need to know what the run method does
name mentioned in the source code” • Weaken the dependency of Timer on TimeToStretch
Main class depends on Timer
Main • Introduce a weaker specification, in the form of an
interface or abstract class
Timer public abstract class TimerTask {
TimeToStretch Timer depends on
public abstract void run();
TimeToStretch }
• Does Timer really need to depend on
TimeToStretch?
• Timer only needs to know that something (e.g.,
• Is Timer re-usable in a new context? TimeToStretch) meets the TimerTask specification

29 30

31 32

TimeToStretch (version 2) Timer v2

public class Timer {
public class TimeToStretch extends TimerTask { private TimerTask task;
public void run() { public Timer(TimerTask task) { this.task = task; }
public void setTask(TimerTask task){this.task = task;}
System.out.println("Stop typing!"); public void start() {
suggestExercise(); while (true) {
} ...
if (enoughTime)
task.run();
public void suggestExercise() { }
... }
} }
} • Main creates the TimeToStretch object and passes it to Timer
Timer t = new Timer(new TimeToStretch());
t.start();
t.setTask(new TimeToSave());
t.start();

31 32

8
 12/13/19

33 34

Module dependency diagram callbacks

• Main still depends on Timer (is this necessary?) • TimeToStretch creates a
Timer, and passes in a reference to
• Main depends on the constructor for
TimeToStretch itself so the Timer can call it back
• This is a callback – a method call from
• Timer depends on TimerTask, not TimeToStretch a module to a client that notifies about
• Unaffected by implementation details of TimeToStretch some condition
• Now Timer is much easier to reuse • Use a callback to invert a dependency
• Inverted dependency:
Main A synchronous callback.
TimeToStretch depends on Timer
Time increases downward.
(not vice versa) Solid lines: calls
TimerTask Timer • Side benefit: Main does not depend on Dotted lines: returns

Dependence
Timer

Subclassing
TimeToStretch

33 34

36 37

TimeToStretch v3 Main v3
public class TimeToStretch extends TimerTask { • TimeToStretch tts = new TimeToStretch();
private Timer timer; Register interest with tts.start();
public TimeToStretch() { the timer • Use a callback to invert a dependency
timer = new Timer(this);
} • This diagram shows the inversion of the dependency
public void start() { Callback entry point between Timer and TimeToStretch (compared to v1)
timer.start();
Main does not depend on Timer
} TimeToStretch depends on Timer
Main
public void run() {
System.out.println("Stop typing!");
suggestExercise(); TimerTask Timer
}
...
} TimeToStretch

36 37

9
 12/13/19

38 39

How do we design classes? Design exercise

• One common approach to class identification is to • Suppose we are writing a birthday-reminder application
consider the specifications that tracks a set of people and their birthdays, providing
• In particular, it is often the case that reminders of whose birthdays are on a given day
• nouns are potential classes, objects, fields
• verbs are potential methods or responsibilities of a class • What classes are we likely to want to have? Why?

Class shout-out about classes

38 39

40

More detail for those classes

• What fields do they have?
• What constructors do they have?
• What methods do they provide?
• What invariants should we guarantee?

In small groups, ~5 minutes

40

10