8. Why do I need SOLID?
It works fine without it...
9. SOLID as a life saver for the main problems of
a bad architecture:
● Fragility
A change may break unexpected parts — it is very difficult to detect if you
don’t have a good test coverage.
● Immobility
A component is difficult to reuse in another project—or in multiple places
of the same project—because it has too many coupled dependencies.
● Rigidity
A change requires a lot of efforts because it affects several parts of the
project.
10. Single responsibility principle
There should never be more than one reason for a class to change
Every time you create/change a class, you should ask yourself:
How many responsibilities does this class have?
15. Single responsibility principle
One of the possible ways to solve AppDelegate overloading is to use
Composite Design Pattern*:
* Highly recommend to
read: Refactoring
Massive App Delegate
16. Open/Closed principle
Entities (classes, modules, functions, etc.) should be open for extension, but
closed for modification.
● Open for extension: You should be able to extend or change the
behaviour of a class without efforts.
● Closed for modification: You must extend a class without changing the
implementation.
19. Liskov substitution principle
Functions that use pointers on base classes must be able to use objects of
derived classes without knowing it.
To avoid violating this principle, the following restrictions must be applied:
● Preconditions cannot be strengthened in the subclass
● Postconditions cannot be weakened in the subclass
23. Interface segregation principle
● "Many specialized interfaces are better than one universal"
or
● "Clients should not depend on methods that they do not use."
25. Dependency inversion principle
High-level modules should not depend on low-level
modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should
depend on abstractions.
Module - a logically interconnected set of functional elements.
