Understanding Software Design Principles and Patterns

 
S
o
f
t
w
a
r
e
 
E
n
g
i
n
e
e
r
i
n
g
a
n
d
 
A
r
c
h
i
t
e
c
t
u
r
e
 
Compositional Design Principles
 
G
a
n
g
 
o
f
 
F
o
u
r
 
(
G
o
F
)
 
 
Erich Gamma, Richard Helm
Ralph Johnson & John Vlissides
 
Design Patterns 
 Elements of
Reusable Object-Oriented Software
 
Addison-Wesley, 1995.
(As CD, 1998)
 
First systematic software pattern
description.
 
CS@AU
 
Henrik Bærbak Christensen
 
2
 
T
h
e
 
m
o
s
t
 
i
m
p
o
r
t
a
n
t
 
c
h
a
p
t
e
r
 
Section 1.6 of GoF has a section called:
 
H
o
w
 
d
e
s
i
g
n
 
p
a
t
t
e
r
n
s
 
s
o
l
v
e
 
d
e
s
i
g
n
 
p
r
o
b
l
e
m
s
 
This section is the gold nugget section
 
It ties the patterns to the underlying coding principles that
delivers the real power.
 
CS@AU
 
Henrik Bærbak Christensen
 
3
 
C
o
m
p
o
s
i
t
i
o
n
a
l
 
D
e
s
i
g
n
 
P
r
i
n
c
i
p
l
e
s
 
CS@AU
 
Henrik Bærbak Christensen
 
4
 
A
s
 
t
h
e
 
3
-
1
-
2
 
p
r
o
c
e
s
s
 
 
CS@AU
 
Henrik Bærbak Christensen
 
5
 
F
i
r
s
t
 
P
r
i
n
c
i
p
l
e
 
CS@AU
 
Henrik Bærbak Christensen
 
6
 
G
o
F
s
 
1
s
t
 
p
r
i
n
c
i
p
l
e
 
Program to an interface, not an implementation
 
 
 
In other words
A
s
s
u
m
e
 
o
n
l
y
 
t
h
e
 
r
o
l
e
(
t
h
e
 
r
e
s
p
o
n
s
i
b
i
l
i
t
i
e
s
 
+
 
p
r
o
t
o
c
o
l
)
 
… and 
never
 allow yourself to be coupled to
implementation details and concrete behavior
 
CS@AU
 
Henrik Bærbak Christensen
 
7
 
F
i
r
s
t
 
P
r
i
n
c
i
p
l
e
 
Program to an interface
 because
Y
o
u
 
o
n
l
y
 
c
o
l
l
a
b
o
r
a
t
e
 
w
i
t
h
 
t
h
e
 
r
o
l
e
 
 
n
o
t
 
a
n
 
i
n
d
i
v
i
d
u
a
l
 
o
b
j
e
c
t
 
You are 
free
 to use 
any
 service provider class!
Any class that implements that interface…
 
You do not delimit other developers for providing 
their
 service
provider class!
 
You avoid binding others to a particular inheritance hierarchy
Which you would do if you use (abstract) classes…
 
CS@AU
 
Henrik Bærbak Christensen
 
8
 
E
x
a
m
p
l
e
 
Early pay station GUI used JLabel for visual output
 
 
 
I only use method: ’setText()’
 
 
CS@AU
 
Henrik Bærbak Christensen
 
9
 
E
x
a
m
p
l
e
 
The I found SoftCollection’s number display, got
permission to use it, but...
 
 
... And use:
 
CS@AU
 
Henrik Bærbak Christensen
 
10
 
M
o
r
a
l
e
 
It would have been easy to make the code completely
identical, and thus support full reuse, in which I simply
configure PayStationGUI with the proper ’text panel’ to
use.
B
u
t
 
I
 
c
a
n
n
o
t
!
Because LCDDigitDisplay does not inherit JLabel!!!
Thus instead of 
dependency injection
 and 
change by
addition
 I get
C
h
a
n
g
e
 
b
y
 
m
o
d
i
f
i
c
a
t
i
o
n
I have to start my editor just to change one declaration!
I can never get a framework out of this!
 
CS@AU
 
Henrik Bærbak Christensen
 
11
 
C
o
u
l
d
 
h
a
v
e
 
b
e
e
n
 
s
o
l
v
e
d
 
If JLabel was an
interface
 instead!
Interface “IJLabel”
setText(String s);
 
Then there would be
no hard coupling to a
specific inheritance
hierarchy.
 
 
CS@AU
 
Henrik Bærbak Christensen
 
12
MyLCDDigitDisplay
 
I
n
t
e
r
f
a
c
e
s
 
a
l
l
o
w
 
f
i
n
e
-
g
r
a
i
n
e
d
 
b
e
h
a
v
i
o
r
a
l
a
b
s
t
r
a
c
t
i
o
n
s
 
Clients can be 
very
 specific about the exact responsibility
it requires from its service provider – 
Role interfaces
 
Example:
Collections.sort(List<T> list)
 
can sort a list of objects of 
any
 type, T, if each object implements
the interface Comparable<? 
s
uper T>
i.e. must implement method ‘int 
c
ompareTo(T o)’.
 
L
o
w
 
c
o
u
p
l
i
n
g
 
 
n
o
 
i
r
r
e
l
e
v
a
n
t
 
m
e
t
h
o
d
 
d
e
p
e
n
d
e
n
c
y
!
 
CS@AU
 
Henrik Bærbak Christensen
 
13
SOL
I
D : I = Interface Segregation
 
I
n
t
e
r
f
a
c
e
s
 
b
e
t
t
e
r
 
e
x
p
r
e
s
s
 
r
o
l
e
s
 
Interfaces express 
specific responsibilities
 whereas
classes express 
concepts
. Concepts usually include
more responsibilities and they become broader!
 
 
 
Small, very well defined, roles are easier to reuse as you
do not get all the “stuff you do not need...”
 
CS@AU
 
Henrik Bærbak Christensen
 
14
 
S
e
c
o
n
d
 
P
r
i
n
c
i
p
l
e
 
 
CS@AU
 
Henrik Bærbak Christensen
 
15
 
G
o
F
s
 
2
n
d
 
p
r
i
n
c
i
p
l
e
 
Favor object composition over class inheritance
What this statement says is that there are basically 
two
ways to reuse code in OO!
 
And
 the compositional one should be 
favored!
 
CS@AU
 
Henrik Bærbak Christensen
 
16
 
B
e
n
e
f
i
t
s
 
o
f
 
c
l
a
s
s
 
i
n
h
e
r
i
t
a
n
c
e
 
C
l
a
s
s
 
i
n
h
e
r
i
t
a
n
c
e
 
You get the “whole packet” and “tweak a bit” by overriding a
single or few methods
Fast and easy (very little typing!)
Explicit in the code, supported by language
(you can directly write “extends”)
 
 
But...
 
CS@AU
 
Henrik Bærbak Christensen
 
17
 
E
n
c
a
p
s
u
l
a
t
i
o
n
 
 
 
“inheritance breaks encapsulation”
 
 
 
Snyder (1986)
 
CS@AU
 
Henrik Bærbak Christensen
 
18
 
W
h
y
?
 
No encapsulation because
Subclass can access every…
instance variable/property
data structure
Method
… of any superclass (except those declared private)
 
T
h
u
s
 
a
 
s
u
b
c
l
a
s
s
 
a
n
d
 
s
u
p
e
r
c
l
a
s
s
 
a
r
e
 
t
i
g
h
t
l
y
 
c
o
u
p
l
e
d
You cannot change the root class’ data structure without
refactoring every subclass in the complete hierarchy 
 
CS@AU
 
Henrik Bærbak Christensen
 
19
 
O
n
l
y
 
a
d
d
 
r
e
s
p
o
n
s
i
b
i
l
i
t
i
e
s
,
 
n
e
v
e
r
 
r
e
m
o
v
e
 
You buy the full package!
All methods, all data structures
Even those that are irrelevant or down right wrong!
 
CS@AU
 
Henrik Bærbak Christensen
 
20
 
E
x
a
m
p
l
e
 
 
Vector<E>
   
(= an ArrayList ‘almost’)
v
oid add(int index, E element)
 
Stack<E> extends Vector<E>
E pop()
void push(E item)
 
 
CS@AU
 
Henrik Bærbak Christensen
 
21
 
R
e
w
r
i
t
i
n
g
 
t
o
 
C
o
m
p
o
s
i
t
i
o
n
 
Class ‘Stack has-a Vector’, instead of ‘Stack is-a Vector’
Much better design!
Stack does not have any
Vector/List methods, only
push() and pop()
 
CS@AU
 
Henrik Bærbak Christensen
 
22
 
C
o
m
p
i
l
e
 
t
i
m
e
 
b
i
n
d
i
n
g
 
 
The only way to change behavior in the future (tweak a
bit more) is through the 
edit-compile-debug-debug-
debug-debug 
cycle
 
 
CS@AU
 
Henrik Bærbak Christensen
 
23
Any implementing class of
List<String> can be substituted
here (by Dependency Injection),
thus no hard coupling between
Stack and “Vector”
 
R
e
c
u
r
r
i
n
g
 
m
o
d
i
f
i
c
a
t
i
o
n
s
 
Constantly bubbling of behavior up into the root class in a
hierarchy
Review the analysis in the State pattern chapter
Another example
Nice service based upon ArrayList
Now – want better performance in new variant
 
 
 
All three classes
modified 
 
CS@AU
 
Henrik Bærbak Christensen
 
24
 
S
e
p
a
r
a
t
e
 
T
e
s
t
i
n
g
 
Often, small and well focused abstractions are easier to
test than large classes
 
 
 
 
a) Only 
integration testing
 possible (NewS. + ExistS.)
b) Allows 
unit testing
 of ‘ExistingService1+2’,
and often 
unit testing
 of NewService, by replacing collaborators
with Test Stubs ala 
StubService1 and StubService2
 
CS@AU
 
Henrik Bærbak Christensen
 
25
I
n
c
r
e
a
s
e
 
p
o
s
s
i
b
i
l
i
t
y
 
o
f
 
r
e
u
s
e
Smaller implementations are easier to reuse
Example from MiniDraw
Sub responsibility
A
l
l
o
w
 
c
o
m
p
o
s
i
t
i
o
n
a
l
 
r
e
u
s
e
 
o
f
 
F
i
g
u
r
e
C
o
l
l
e
c
t
i
o
n
 
i
n
 
a
l
l
p
r
e
s
e
n
t
 
a
n
d
 
f
u
t
u
r
e
 
i
m
p
l
.
 
o
f
 
D
r
a
w
i
n
g
!
CS@AU
Henrik Bærbak Christensen
26
 
L
i
a
b
i
l
i
t
i
e
s
 
Increased number of abstractions and objects 
 
 
Delegation requires more boiler-plate code 
 
CS@AU
 
Henrik Bærbak Christensen
 
27
(
w
h
a
t
 
i
s
 
h
e
 
s
a
y
i
n
g
?
?
?
)
Inheritance is an interesting construct, but
It often leads to lesser designs 
It does not elegantly handle
ad hoc reuse
modelling roles
variance of behavior
CS@AU
Henrik Bærbak Christensen
28
 
W
h
e
n
 
t
o
 
u
s
e
 
I
n
h
e
r
i
t
a
n
c
e
?
 
My rule of thumb
Iff there is 
behavioral differences
 between subclasses
Not just parameters and constants; it must be different algorithms
Iff you are absolutely sure there will be only one dimension of
variability and a shallow inheritance tree…
Often I later find I can rewrite it…
E2023
 
E2024
 
Gfx rendering difference is just a set of
parameters… See slides in Week 9 
 
CS@AU
 
Henrik Bærbak Christensen
 
29
 
T
h
i
r
d
 
P
r
i
n
c
i
p
l
e
 
CS@AU
 
Henrik Bærbak Christensen
 
30
 
G
o
F
s
 
3
r
d
 
p
r
i
n
c
i
p
l
e
 
Consider what should be variable in your
design
[GoF §1.8, p.29]
 
 
Another way of expressing the 3rd principle:
Encapsulate the behavior that varies
 
CS@AU
 
Henrik Bærbak Christensen
 
31
 
A
n
a
l
y
s
i
s
 
This statement is closely linked to the shorter
Change by addition, not by modification
That is – you identify
the design/code that should remain 
stable
the design/code that may vary
and use techniques that ensure that the stable part – well
– remain stable
 
These techniques are 1st and 2nd principle
most of the time 
 
CS@AU
 
Henrik Bærbak Christensen
 
32
 
T
h
e
 
P
r
i
n
c
i
p
l
e
s
 
I
n
 
A
c
t
i
o
n
 
 
CS@AU
 
Henrik Bærbak Christensen
 
33
 
P
r
i
n
c
i
p
l
e
s
 
i
n
 
a
c
t
i
o
n
 
Applying the principles lead to basically the same
structure of most patterns:
New requirement to our client code
 
C
l
i
e
n
t
 
CS@AU
 
Henrik Bærbak Christensen
 
34
P
r
i
n
c
i
p
l
e
s
 
i
n
 
a
c
t
i
o
n
Applying the principles lead to basically the same
structure of most patterns:
 Consider what should be variable
C
l
i
e
n
t
 
 
V
a
r
i
a
b
i
l
i
t
y
CS@AU
Henrik Bærbak Christensen
35
P
r
i
n
c
i
p
l
e
s
 
i
n
 
a
c
t
i
o
n
Applying the principles lead to basically the same
structure of most patterns:
 Program to an interface
C
l
i
e
n
t
 
 
«
i
n
t
e
r
f
a
c
e
»
V
a
r
i
a
b
i
l
i
t
y
CS@AU
Henrik Bærbak Christensen
36
P
r
i
n
c
i
p
l
e
s
 
i
n
 
a
c
t
i
o
n
Applying the principles lead to basically the same
structure of most patterns:
 Favor object composition
C
l
i
e
n
t
«interface»
V
a
r
i
a
b
i
l
i
t
y
CS@AU
Henrik Bærbak Christensen
37
 
A
n
d
 
t
h
a
t
 
i
s
 
w
h
y
 
… most patterns follows this structure exactly
They encapsulate variability and favor composition
 
CS@AU
 
Henrik Bærbak Christensen
 
38
C
l
i
e
n
t
«interface»
V
a
r
i
a
b
i
l
i
t
y
 
S
u
m
m
a
r
y
 
 
We 
identified some
behaviour
 that was 
likely to
change
 
 
We stated a 
well defined
responsibility
 that covers this
behaviour and expressed it in
an 
interface
 
 
Instead of performing
behaviour ourselves we
delegated
 to an object
implementing the interface
 
 Consider what should be
variable in your design
 
 
 
Program to an interface, not
an implementation
 
 
 
Favor object composition
over class inheritance
 
 
CS@AU
 
Henrik Bærbak Christensen
 
39
 
S
O
L
I
D
 
A more well known set of principles than

, but states
more or less the same…
 
CS@AU
 
Henrik Bærbak Christensen
 
40
 
S
O
L
I
D
 
i
s
 
S
o
l
i
d
 
An architectural style for 
large systems:
 Microservices
Key architecture for Uber, Google, NetFlix, …
Lots of tooling, lots of architectural tactics, lots of design
doctrines to follow, but…
 
 
At the core, it is..
Design with high cohesion and low coupling
Design according to SOLID
P
r
o
g
r
a
m
 
t
o
 
a
n
 
i
n
t
e
r
f
a
c
e
,
 
f
a
v
o
r
 
o
b
j
e
c
t
 
c
o
m
p
o
s
i
t
i
o
n
 
CS@AU
 
Henrik Bærbak Christensen
 
41
Uber Data
Slide Note
Embed
Share

Delve into the world of software engineering and architecture through the lens of compositional design principles and the renowned Gang of Four (GoF) design patterns. Explore how design patterns solve complex problems and learn about the significance of programming to an interface rather than an implementation. Gain insights into practical examples highlighting the importance of collaboration, flexibility, and abstraction in software development.


Uploaded on Sep 14, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Software Engineering and Architecture Compositional Design Principles

  2. Gang of Four (GoF) Erich Gamma, Richard Helm Ralph Johnson & John Vlissides Design Patterns Elements of Reusable Object-Oriented Software Addison-Wesley, 1995. (As CD, 1998) First systematic software pattern description. CS@AU Henrik B rbak Christensen 2

  3. The most important chapter Section 1.6 of GoF has a section called: How design patterns solve design problems This section is the gold nugget section It ties the patterns to the underlying coding principles that delivers the real power. CS@AU Henrik B rbak Christensen 3

  4. Compositional Design Principles CS@AU Henrik B rbak Christensen 4

  5. As the 3-1-2 process CS@AU Henrik B rbak Christensen 5

  6. First Principle CS@AU Henrik B rbak Christensen 6

  7. GoFs 1st principle Program to an interface, not an implementation In other words Assume only the role (the responsibilities + protocol) and never allow yourself to be coupled to implementation details and concrete behavior CS@AU Henrik B rbak Christensen 7

  8. First Principle Program to an interface because You only collaborate with the role not an individual object You are free to use any service provider class! Any class that implements that interface You do not delimit other developers for providing their service provider class! You avoid binding others to a particular inheritance hierarchy Which you would do if you use (abstract) classes CS@AU Henrik B rbak Christensen 8

  9. Example Early pay station GUI used JLabel for visual output I only use method: setText() CS@AU Henrik B rbak Christensen 9

  10. Example The I found SoftCollection s number display, got permission to use it, but... ... And use: CS@AU Henrik B rbak Christensen 10

  11. Morale It would have been easy to make the code completely identical, and thus support full reuse, in which I simply configure PayStationGUI with the proper text panel to use. But I cannot! Because LCDDigitDisplay does not inherit JLabel!!! Thus instead of dependency injection and change by addition I get Change by modification I have to start my editor just to change one declaration! I can never get a framework out of this! CS@AU Henrik B rbak Christensen 11

  12. Could have been solved If JLabel was an interface instead! Interface IJLabel setText(String s); LCDDigitDisplay GUI IJLabel JLabel Then there would be no hard coupling to a specific inheritance hierarchy. MyLCDDigitDisplay CS@AU Henrik B rbak Christensen 12

  13. Interfaces allow fine-grained behavioral abstractions Clients can be very specific about the exact responsibility it requires from its service provider Role interfaces SOLID : I = Interface Segregation Example: Collections.sort(List<T> list) can sort a list of objects of any type, T, if each object implements the interface Comparable<? super T> i.e. must implement method int compareTo(T o) . Low coupling no irrelevant method dependency! CS@AU Henrik B rbak Christensen 13

  14. Interfaces better express roles Interfaces express specific responsibilities whereas classes express concepts. Concepts usually include more responsibilities and they become broader! Small, very well defined, roles are easier to reuse as you do not get all the stuff you do not need... CS@AU Henrik B rbak Christensen 14

  15. Second Principle CS@AU Henrik B rbak Christensen 15

  16. GoFs 2nd principle Favor object composition over class inheritance What this statement says is that there are basically two ways to reuse code in OO! And the compositional one should be favored! CS@AU Henrik B rbak Christensen 16

  17. Benefits of class inheritance Class inheritance You get the whole packet and tweak a bit by overriding a single or few methods Fast and easy (very little typing!) Explicit in the code, supported by language (you can directly write extends ) But... CS@AU Henrik B rbak Christensen 17

  18. Encapsulation inheritance breaks encapsulation Snyder (1986) CS@AU Henrik B rbak Christensen 18

  19. Why? No encapsulation because Subclass can access every instance variable/property data structure Method of any superclass (except those declared private) Thus a subclass and superclass are tightly coupled You cannot change the root class data structure without refactoring every subclass in the complete hierarchy CS@AU Henrik B rbak Christensen 19

  20. Only add responsibilities, never remove You buy the full package! All methods, all data structures Even those that are irrelevant or down right wrong! CS@AU Henrik B rbak Christensen 20

  21. Example Vector<E> void add(int index, E element) (= an ArrayList almost ) Stack<E> extends Vector<E> E pop() void push(E item) Argue why this is a design with many liabilities? How can you rewrite it elegantly using composition? Henrik B rbak Christensen CS@AU 21

  22. Rewriting to Composition Class Stack has-a Vector , instead of Stack is-a Vector Much better design! Stack does not have any Vector/List methods, only push() and pop() CS@AU Henrik B rbak Christensen 22

  23. Compile time binding The only way to change behavior in the future (tweak a bit more) is through the edit-compile-debug-debug- debug-debug cycle Any implementing class of List<String> can be substituted here (by Dependency Injection), thus no hard coupling between Stack and Vector CS@AU Henrik B rbak Christensen 23

  24. Recurring modifications Constantly bubbling of behavior up into the root class in a hierarchy Review the analysis in the State pattern chapter Another example Nice service based upon ArrayList Now want better performance in new variant All three classes modified CS@AU Henrik B rbak Christensen 24

  25. Separate Testing Often, small and well focused abstractions are easier to test than large classes a) Only integration testing possible (NewS. + ExistS.) b) Allows unit testingof ExistingService1+2 , and often unit testing of NewService, by replacing collaborators with Test Stubs ala StubService1 and StubService2 CS@AU Henrik B rbak Christensen 25

  26. Increase possibility of reuse Smaller implementations are easier to reuse Example from MiniDraw Sub responsibility Allow compositional reuse of FigureCollection in all present and future impl. of Drawing! CS@AU Henrik B rbak Christensen 26

  27. Liabilities Increased number of abstractions and objects Delegation requires more boiler-plate code CS@AU Henrik B rbak Christensen 27

  28. (what is he saying???) Inheritance is an interesting construct, but It often leads to lesser designs It does not elegantly handle ad hoc reuse modelling roles variance of behavior CS@AU Henrik B rbak Christensen 28

  29. When to use Inheritance? My rule of thumb Iff there is behavioral differences between subclasses Not just parameters and constants; it must be different algorithms Iff you are absolutely sure there will be only one dimension of variability and a shallow inheritance tree Often I later find I can rewrite it E2023 E2024 Gfx rendering difference is just a set of parameters See slides in Week 9 CS@AU Henrik B rbak Christensen 29

  30. Third Principle CS@AU Henrik B rbak Christensen 30

  31. GoFs 3rd principle Consider what should be variable in your design [GoF 1.8, p.29] Another way of expressing the 3rd principle: Encapsulate the behavior that varies CS@AU Henrik B rbak Christensen 31

  32. Analysis This statement is closely linked to the shorter Change by addition, not by modification That is you identify the design/code that should remain stable the design/code that may vary and use techniques that ensure that the stable part well remain stable These techniques are 1st and 2nd principle most of the time CS@AU Henrik B rbak Christensen 32

  33. The Principles In Action CS@AU Henrik B rbak Christensen 33

  34. Principles in action Applying the principles lead to basically the same structure of most patterns: New requirement to our client code Client CS@AU Henrik B rbak Christensen 34

  35. Principles in action Applying the principles lead to basically the same structure of most patterns: Consider what should be variable Client Variability CS@AU Henrik B rbak Christensen 35

  36. Principles in action Applying the principles lead to basically the same structure of most patterns: Program to an interface interface Variability Client CS@AU Henrik B rbak Christensen 36

  37. Principles in action Applying the principles lead to basically the same structure of most patterns: Favor object composition interface Variability Client ConcreteVariation1 ConcreteVariation2 CS@AU Henrik B rbak Christensen 37

  38. And that is why most patterns follows this structure exactly They encapsulate variability and favor composition interface Variability Client ConcreteVariation1 ConcreteVariation2 CS@AU Henrik B rbak Christensen 38

  39. Summary We identified some behaviour that was likely to change Consider what should be variable in your design We stated a well defined responsibility that covers this behaviour and expressed it in an interface Program to an interface, not an implementation Favor object composition over class inheritance Instead of performing behaviour ourselves we delegated to an object implementing the interface CS@AU Henrik B rbak Christensen 39

  40. SOLID A more well known set of principles than more or less the same , but states CS@AU Henrik B rbak Christensen 40

  41. SOLID is Solid An architectural style for large systems: Microservices Key architecture for Uber, Google, NetFlix, Lots of tooling, lots of architectural tactics, lots of design doctrines to follow, but Uber Data At the core, it is.. Design with high cohesion and low coupling Design according to SOLID Program to an interface, favor object composition CS@AU Henrik B rbak Christensen 41

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#