А short introduction in the common Design principles

1. 7/25/19
Design Principles
Ivelin Yanev

2. 7/25/19
Good Design
●
A good design is a design that’s easy to change.
●
Correct solution takes iterations, constantly in evolution.
●
Writing code first time is an exploration: many relationships are discovered,
questions asked and answered.
●
When we’re done, we should (utopically) delete it and rewrite it.
2
Almost impossible to get it right the first time

3. 7/25/19
How to make a good design?
●
Too much ego: can’t let go of our bad designs
●
Code review and discussion
●
Care about solving the problem, not a specific implementation
3
Software is never written, it is always rewritten. As the
software that is relevant always must be changed

4. 7/25/19
Cohesion
●
Tight Coupling(a bad programming design). Depending on a class is a tight
coupling.
●
Loose Coupling(a good programming design). Depending on an interface is a
loose coupling.
A good design has high cohesion and low coupling
4

5. 7/25/19
DRY (Do not Repeat Yourself)
●
Don’t duplicate code itself
●
It reduces the cost of development
●
Refactor when you notice duplication
5

6. 7/25/19
SOLID
●
Single responsibility principle
●
Open-Closed Principle
●
Liskov substitution principle
●
Interface segregation principle
●
Dependency inversion principle
6

7. 7/25/19
Single responsibility principle
●
A class should have only a single responsibility
●
Cohesive class has single responsibility
●
Long methods are bad
7

8. 7/25/19
Open-Closed Principle
“Software entities (classes, modules, functions, etc.) should be open for
extension, but closed for modification.”
“A class is closed, since it may be compiled, stored in a library, baselined, and
used by client classes. But it is also open, since any new class may use it as
parent, adding new features. When a descendant class is defined, there is no
need to change the original or to disturb its clients.”
8

9. 7/25/19
Liskov substitution principle
Methods that use references to the base classes must be able to use the
objects of the derived classes without knowing it.
9

10. 7/25/19
Interface segregation principle
Many client-specific interfaces are better than one general-purpose interface
10

11. 7/25/19
Dependency inversion principle
●
High-level modules should not depend on low-level modules. Both should
depend on abstractions.
●
Depend on abstraction (like interfaces) instead of concrete classes
11

12. 7/25/19
"In the one and only true way. The object-oriented version of 'Spaghetti code' is,
of course, 'Lasagna code'. (Too many layers)."
12