Open Closed Principle
Software entities (classes, modules,
functions, etc) should be open for
extension, but closed for modification.
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
A better solution
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
How to get the API?
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
There may be no more than one switch statement
for a given type of selection. The cases in that
switch statement must create polymorphic objects
that take the place of such switch statements in
the rest of the system
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
A small sidestep...
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
Open Closed Principle
1. Since changing code introduces errors
2. Try to minimize change
3. And use polymorphism to solve our problems
Slide 22
Slide 22 text
Liskov Substitution Principle
Functions that use pointers or references
to base classes must be able to use objects
of derived classes without knowing it
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
Design by contract
Preconditions
Postcondition
Input and output variables
And more...
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
Liskov Substitution Principle
1. Indispensable when adhering to the OCP
2. Only when a subclass can be used as its
parent in every respect, functions using that
parents can be reused without impunity.
Slide 29
Slide 29 text
Dependency Inversion Principle
A. High-level modules should not depend
on low level modules. Both should depend
on abstractions.
B. Abstractions should not depend upon
details. Details should depend upon
abstractions.
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
Dependency Inversion Principle
1. Implementation details hide behind
abstractions
2. Other code depends upon these abstractions
Slide 36
Slide 36 text
Interface Segregation Principle
Clients should not be forced to depend
upon interfaces that they do not use.
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
Interface Segregation Principle
1. Design interfaces based on use-cases
2. Stop pollution from seeping in
Slide 42
Slide 42 text
Single Responsibility Principle
There should never be more than one
reason for a class to change.
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
Single Responsibility Principle
The most simple principle to
understand, the hardest to get
right