Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Clean code: SOLID (iOS)

20 Aufrufe

Veröffentlicht am

SOLID as a lifesaver for the main problems of bad architecture.

Veröffentlicht in: Mobil
  • Als Erste(r) kommentieren

Clean code: SOLID (iOS)

  1. 1. Clean code: SOLID Maksym Husar Mobile Team Lead, Indeema Software Inc.
  2. 2. Why do I need it?
  3. 3. The main reason why Be relaxed. Keep calm.
  4. 4. One more reason why
  5. 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. 6. SOLID
  7. 7. SOLID principles
  8. 8. Why do I need SOLID? It works fine without it...
  9. 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. 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. 11. ==> Single responsibility principle
  12. 12. Single responsibility principle ==>
  13. 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. 14. Single responsibility principle App Delegate is the most popular violator of the SRP principle.
  15. 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. 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. 17. Open/Closed principle
  18. 18. Open/Closed principle ==> *Decorator Design pattern is mainly focused on Open/Closed Principle.
  19. 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
  20. 20. Liskov substitution principle. Bad inheritance example. ==>
  21. 21. Liskov substitution principle. Condition example.
  22. 22. Interface segregation principle ● "Many specialized interfaces are better than one universal" or ● "Clients should not depend on methods that they do not use."
  23. 23. Interface segregation principle
  24. 24. 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.
  25. 25. Dependency inversion principle Change in Е Arrows show the direction of the relationship between the modules.
  26. 26. Dependency inversion principle Depend on abstractions, not on details.
  27. 27. DataHandler FilesystemStorage Dependency inversion principle
  28. 28. Dependency inversion principle DataHandler Storage FilesystemStorage DropboxCloudStorage
  29. 29. Dependency inversion principle. Bad example.
  30. 30. Dependency inversion principle. Good example.
  31. 31. Obj-C & Swift Dependencies Visualizer https://github.com/PaulTaykalo/ objc-dependency-visualizer
  32. 32. Most popular Dependency injection libraries Swinject - https://github.com/Swinject/Swinject Cleanse - https://github.com/square/Cleanse Needle - https://github.com/uber/needle
  33. 33. 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
  34. 34. 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