Design principles are a matter of the utmost importance for the software development, but unfortunately by far not all developers are closely acquainted with them. In this presentation we cover the basics of the core design and development principles.
8. How to make a good design?
▪ Let go of the ego
▪ Be unemotional
9. How to make a good design?
▪ Let go of the ego
▪ Be unemotional
▪ Do code reviews
10. How to make a good design?
▪ Let go of the ego
▪ Be unemotional
▪ Do code reviews
▪ A good design is the one that hides inherited complexity and eliminates the
accidental complexity
11. How to make a good design?
▪ Let go of the ego
▪ Be unemotional
▪ Do code reviews
▪ A good design is the one that hides inherited complexity and eliminates the
accidental complexity
Software is never written, it is always rewritten. As the
software that is relevant always must be changed
16. What is simple?
▪ Simple makes you concentrated
▪ Simple resolves only actual issues we know about
17. What is simple?
▪ Simple makes you concentrated
▪ Simple resolves only actual issues we know about
▪ Simple fails less
18. What is simple?
▪ Simple makes you concentrated
▪ Simple resolves only actual issues we know about
▪ Simple fails less
▪ Simple is easier to understand
20. Think YAGNI
Do we
need
it?
Day
1
We have to ask ourselves whether we need it today or not. If it's possible to
postpone something constantly for a few iterations maybe you don't need it at all.
21. Think YAGNI
Do we
need
it?
Day
1
Do we
actually
need
it?
Day
5
We have to ask ourselves whether we need it today or not. If it's possible to
postpone something constantly for a few iterations maybe you don't need it at all.
22. Think YAGNI
Do we
need
it?
Day
1
Do we
actually
need
it?
Day
5
We do
not
need it
Day
9
We have to ask ourselves whether we need it today or not. If it's possible to
postpone something constantly for a few iterations maybe you don't need it at all.
23. Cost of implementing
Smart Smarter
Much
smarter
Now correlation Later Result
X > Y Postpone
X == Y Postpone
X < Y ?
26. Coupling
▪ Coupling is what you depend on...
▪ Inheritance is the worst form of coupling
27. Coupling
▪ Coupling is what you depend on...
▪ Inheritance is the worst form of coupling
▪ "knock out before mock out“
28. Coupling
▪ Coupling is what you depend on....
▪ Inheritance is the worst form of coupling
▪ "knock out before mock out“
▪ Depending on a class is a tight coupling
29. Coupling
▪ Coupling is what you depend on....
▪ Inheritance is the worst form of coupling
▪ "knock out before mock out“
▪ Depending on a class is a tight coupling
▪ Depending on an interface is a loose coupling
30. Coupling
▪ Coupling is what you depend on....
▪ Inheritance is the worst form of coupling
▪ "knock out before mock out“
A good design has high cohesion and low coupling
▪ Depending on a class is a tight coupling
▪ Depending on an interface is a loose coupling
31. DRY ( Do not Repeat Yourself )
▪ Every piece of knowledge in a system should have a single unambiguous
authoritative representation
▪ It reduces the cost of development
36. Single responsibility principle
▪ A class should have only a single responsibility
▪ Cohesive class has single responsibility
▪ When you say "this class does this AND that" you have violated SRP
37. Single responsibility principle
▪ A class should have only a single responsibility
▪ Cohesive class has single responsibility
▪ When you say "this class does this AND that" you have violated SRP
▪ Long methods are bad
40. Commenting
▪ Comments are usually used to cover bad code
▪ When code is not self-evident refactor it
41. Commenting
▪ Comments are usually used to cover bad code
▪ When code is not self-evident refactor it
▪ Don't comment what, instead comment why
42. Commenting
▪ Comments are usually used to cover bad code
▪ When code is not self-evident refactor it
▪ Don't comment what, instead comment why
▪ A good code is like a joke
43. Commenting
▪ Comments are usually used to cover bad code
▪ When code is not self-evident refactor it
▪ Don't comment what, instead comment why
▪ A good code is like a joke
▪ Compose method pattern
45. Open-Closed Principle
▪ Two options - to make an enhancement
1. Change existing code
2. Add a small new module of code
46. Open-Closed Principle
▪ Two options - to make an enhancement
1. Change existing code
2. Add a small new module of code
▪ Nobody likes existing code
47. Open-Closed Principle
▪ Two options - to make an enhancement
1. Change existing code
2. Add a small new module of code
▪ Nobody likes existing code
▪ Software module should be open for extension but closed from modification
48. Open-Closed Principle
▪ Two options - to make an enhancement
1. Change existing code
2. Add a small new module of code
▪ Nobody likes existing code
▪ Software module should be open for extension but closed from modification
▪ Rely on abstraction and polymorphism
52. Liskov substitution principle
▪ Inheritance is overused
▪ If an object of B should be used anywhere an object of A is used then use inheritance
53. Liskov substitution principle
▪ Inheritance is overused
▪ If an object of B should be used anywhere an object of A is used then use inheritance
▪ If an object of B should use an object of A, then use composition / delegation
54. Liskov substitution principle
▪ Inheritance is overused
▪ If an object of B should be used anywhere an object of A is used then use inheritance
▪ If an object of B should use an object of A, then use composition / delegation
▪ Inheritance demands more from a developer than composition or delegation does
55. Liskov substitution principle
▪ Objects in a program should be replaceable with instances of their
subtypes without altering the correctness of that program
▪ The user of a base class should be able to use an instance of a derived class
without knowing the difference
56.
57. Interface segregation principle
▪ Many client-specific interfaces are better than one general-purpose interface
Alarm
Clock PCPhone TV Rooster…
Clock vs
59. Dependency inversion principle
▪ High-level modules should not depend on low-level modules. Both should depend
on abstractions
▪ Abstractions should not depend upon details. Details should depend upon
abstractions
60.
61. Dependency injection pattern
▪ Dependency inversion ≠ dependency injection
▪ Dependency injection pattern is an implementation of Dependency inversion
principle
*Single responsibility principle*
Cohesive class has single responsibility
When you say "this class does this AND that" you have violated SRP
Long methods are bad
*Open-Closed Principle*
Two options - to make an enhancement
1. change existing code
2. add a small new module of code
nobody like existing code
Software module should be open for extension but closed from modification
Rely on abstraction and polymorhism
*Liskov substitution principle*
Inheretence is overused
If an object of B should be used anywhere an object of A is used then use inheritance
If an object of B should use an object of A, then use composition / delegation
Inheritance demands more from a developer than composition or delegation does.
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
The user of a base class should be able to use an instance of a derived class without knowing the difference.
*Interface segregation principle*
many client-specific interfaces are better than one general-purpose interface
Clock example
Alarm
^
|
__________________________________________________________
| | | ....... |
TV Clock SPhone Wife
*Dependency injection principle*
A class should not depende on another class, they both have to depend on an abstraction (interface)
i.e. only one potential change in the software's specification should be able to affect the specification of the class
i.e. only one potential change in the software's specification should be able to affect the specification of the class
i.e. only one potential change in the software's specification should be able to affect the specification of the class
i.e. only one potential change in the software's specification should be able to affect the specification of the class
i.e. only one potential change in the software's specification should be able to affect the specification of the class