Design Patterns
Loose coupling
A general principle to make (software) systems easier to maintain by heavily relying on all kinds of indirections.
A should not refer to B but rely on some mechanism that will associate it with B. It should be easy to substitute B for Bʼ.
a loosely coupled system is one
in which components are weakly associated with each other, and thus changes in one component least affect existence or
performance of another component
in which each of its components has, or makes use of little or no knowledge of the definitions of other separate components.
Tight vs loose coupling
Heuristic 1: Law of demeter
A method m sitting in some object o may only send messages to the following objects:
this (+ itʼs vals and vars)
mʼs parameters
local variables
objects created in m
variables in the scope of m
>
- Make class structures easier to replace without having to change existing code.
An method should not send messages to objects returned by other methods or to objects acquired by accessing sequences of
public instance variables.
In Scala that boils down to “use only one dotˮ in expressions such as “o.m().n().p()ˮ or “o.m.n.p()ˮ
You should only rely on the interface of an object, not on its constituents
Design Patterns 1
, Heuristic 2: SOLID principles
make designs easier to change without having to change existing code.
Single responsibility principle: a class should have one and only one reason to change
Same as ADT-design
Open-closed principle: the ability to extend the behaviour of a class, without modifying it
Design Patterns
Liskov substitution principle: derived classes must be substitutable for their base classes
Design Hierarchies
Interface segregation principle: make fine-grained interfaces that are client-specific
Use Traits
Dependency inversion principle: depend on abstractions, not on concrete implementations
Build software frameworks, not just programs. Use the Hollywood principle.
↳
don't coll us , we be call
you
GOF
Strategy pattern
Definieer een “familieˮ van gelijksoortige algoritmen, encapsuleer deze in een hiërarchie van strategieën, en maak de algoritmen
dynamisch uitwisselbaar. Het werk wordt gedelegeerd naar de strategie.
losed principle
·
,
open
main object - behaviour
·
Design Patterns 2
Loose coupling
A general principle to make (software) systems easier to maintain by heavily relying on all kinds of indirections.
A should not refer to B but rely on some mechanism that will associate it with B. It should be easy to substitute B for Bʼ.
a loosely coupled system is one
in which components are weakly associated with each other, and thus changes in one component least affect existence or
performance of another component
in which each of its components has, or makes use of little or no knowledge of the definitions of other separate components.
Tight vs loose coupling
Heuristic 1: Law of demeter
A method m sitting in some object o may only send messages to the following objects:
this (+ itʼs vals and vars)
mʼs parameters
local variables
objects created in m
variables in the scope of m
>
- Make class structures easier to replace without having to change existing code.
An method should not send messages to objects returned by other methods or to objects acquired by accessing sequences of
public instance variables.
In Scala that boils down to “use only one dotˮ in expressions such as “o.m().n().p()ˮ or “o.m.n.p()ˮ
You should only rely on the interface of an object, not on its constituents
Design Patterns 1
, Heuristic 2: SOLID principles
make designs easier to change without having to change existing code.
Single responsibility principle: a class should have one and only one reason to change
Same as ADT-design
Open-closed principle: the ability to extend the behaviour of a class, without modifying it
Design Patterns
Liskov substitution principle: derived classes must be substitutable for their base classes
Design Hierarchies
Interface segregation principle: make fine-grained interfaces that are client-specific
Use Traits
Dependency inversion principle: depend on abstractions, not on concrete implementations
Build software frameworks, not just programs. Use the Hollywood principle.
↳
don't coll us , we be call
you
GOF
Strategy pattern
Definieer een “familieˮ van gelijksoortige algoritmen, encapsuleer deze in een hiërarchie van strategieën, en maak de algoritmen
dynamisch uitwisselbaar. Het werk wordt gedelegeerd naar de strategie.
losed principle
·
,
open
main object - behaviour
·
Design Patterns 2
