This document discusses the SOLID principles for clean code architecture. It explains each principle individually: single responsibility (a class should have one responsibility), open/closed (classes should be open for extension but closed for modification), Liskov substitution (functions using base classes must work with derived classes), interface segregation (split interfaces into smaller interfaces that are focused), and dependency inversion (high level modules shouldn't depend on low level modules). Following these principles helps produce code that is less fragile, more flexible, and easier to maintain and change over time.

1. Clean code: SOLID
Maksym Husar
Mobile Team Lead, Indeema Software Inc.

2. Why do I need it?

3. The main reason why
Be relaxed. Keep calm.

4. One more reason why

5. First steps to Clean Code
DRY - «Don't repeat yourself»
KISS - «Keep it short and simple»
YAGNI - «You aren't gonna need it»

6. SOLID

7. SOLID principles

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?

11. ==>
Single responsibility principle

12. Single responsibility principle
==>

13. Command-line script for showing the number of lines in a project:
find . -type f -exec wc -l {} + | sort -n
Basic check on clean code issues

14. Single responsibility principle
App Delegate is the most popular violator of the SRP principle.

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.

17. Open/Closed principle

18. Open/Closed principle
==>
*Decorator Design pattern is mainly focused on Open/Closed Principle.

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

21. Liskov substitution principle. Bad inheritance example.
==>

22. Liskov substitution principle. Condition example.

23. Interface segregation principle
● "Many specialized interfaces are better than one universal"
or
● "Clients should not depend on methods that they do not use."

24. Interface segregation principle

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.

26. Dependency inversion principle
Change in Е
Arrows show the direction of the relationship between the
modules.

27. Dependency inversion principle
Depend on abstractions,
not on details.

28. DataHandler
FilesystemStorage
Dependency inversion principle

29. Dependency inversion principle DataHandler
Storage
FilesystemStorage DropboxCloudStorage

30. Dependency inversion principle. Bad example.

31. Dependency inversion principle. Good example.

32. Obj-C & Swift Dependencies Visualizer
https://github.com/PaulTaykalo/
objc-dependency-visualizer

33. Most popular Dependency injection libraries
Swinject - https://github.com/Swinject/Swinject
Cleanse - https://github.com/square/Cleanse
Needle - https://github.com/uber/needle

34. Single responsibility - make modules smaller / simpler
Open/Closed - make modules extendable
Liskov substitution - inherit correctly
Interface segregation - split interfaces/protocols
Dependency inversion - use interfaces/protocols
Summary

35. https://www.scaledrone.com/blog/solid-principles-for-becoming-a-better-ios-
swift-developer/
https://marcosantadev.com/solid-principles-applied-swift/
https://medium.com/swift-india/solid-principles-part-1-single-responsibility-
ccfd4ff34a5a
https://www.vadimbulavin.com/refactoring-massive-app-delegate/
https://www.vadimbulavin.com/dependency-injection-in-swift/
Useful links