Single-responsibility principle meets the real world!

Presented at BlrDroid + BlrKotlin meetup on Aug 19, 2023.

"No plan survives contact with the enemy." goes an adage. This is sadly true for most software engineering principles too. Developers must constantly work against entropy to restore order in their codebases.

SOLID principles have guided many developers to validate their solutions and have helped many build maintainable software systems. However, it can be daunting to practice in the real world without constant feedback, upskilling, and support from peers and tooling.

In this talk, we aim to take a closer look at the first of the five object-oriented design principles from SOLID—Single-responsibility principle. We'll look at large classes and how they violate SRP. We'll also discuss insights and heuristics to identify each of these responsibilities.

What's good comes out of mere insights and heuristics? We'll also put these to good use in practice. At the end of the session, we'll pick one of the most popular messaging apps on Android and do the following,

- Visualize it with tooling
- Identify multiple responsibilities
- Discuss code smells
- Extract at least one responsibility into a separate class without tests

Transcript

1. @ragunathjawahar / legacycode.com Single-responsibility principle
2. @ragunathjawahar / legacycode.com Single-responsibility principle meets the real world! 🥳
3. SOLID @ragunathjawahar / legacycode.com
4. SOLID @ragunathjawahar / legacycode.com
5. Single-responsibility principle • Every class should have only one responsibility • A class should have only one reason to change • A module should be responsible to one, and only one, actor @ragunathjawahar / legacycode.com
6. Why do we have large classes? @ragunathjawahar / legacycode.com
7. Why do we have large classes? • Code smells • Long methods • Feature-envy • Too many methods/functions • Missing abstraction • Duplication • Primitive obsession • Data clumps • … • Developer churn • No tests • Cross-cutting concerns • Utilities • High-level classes
8. Why do we have large classes? • Code smells • Long methods • Feature-envy • Too many methods/functions • Missing abstraction • Duplication • Primitive obsession • Data clumps • … • Developer churn • No tests • Cross-cutting concerns • Utilities • High-level classes
9. High-level classes The term "high-level classes" typically refers to classes that operate at a higher level of abstraction compared to other classes in the system. They generally encapsulate broad concepts, complex behaviors, or orchestration tasks rather than speci fi c, detailed implementations. @ragunathjawahar / legacycode.com
10. High-level classes The term "high-level classes" typically refers to classes that operate at a higher level of abstraction compared to other classes in the system. They generally encapsulate broad concepts, complex behaviors, or orchestration tasks rather than speci fi c, detailed implementations. @ragunathjawahar / legacycode.com
11. High-level classes The term "high-level classes" typically refers to classes that operate at a higher level of abstraction compared to other classes in the system. They generally encapsulate broad concepts, complex behaviors, or orchestration tasks rather than speci fi c, detailed implementations. @ragunathjawahar / legacycode.com
12. High-level classes The term "high-level classes" typically refers to classes that operate at a higher level of abstraction compared to other classes in the system. They generally encapsulate broad concepts, complex behaviors, or orchestration tasks rather than speci fi c, detailed implementations. @ragunathjawahar / legacycode.com
13. High-level classes The term "high-level classes" typically refers to classes that operate at a higher level of abstraction compared to other classes in the system. They generally encapsulate broad concepts, complex behaviors, or orchestration tasks rather than speci fi c, detailed implementations. @ragunathjawahar / legacycode.com
14. High-level classes The term "high-level classes" typically refers to classes that operate at a higher level of abstraction compared to other classes in the system. They generally encapsulate broad concepts, complex behaviors, or orchestration tasks rather than speci fi c, detailed implementations. @ragunathjawahar / legacycode.com
15. TLDR; They just have too many things to do 🤷 @ragunathjawahar / legacycode.com
16. How do we deal with them? @ragunathjawahar / legacycode.com
17. —Albert Einstein “We cannot solve our problems with the same thinking we used when we created them.”
18. Eureka + StoryViewerPageFragment.kt @ragunathjawahar / legacycode.com
19. Eureka + StoryViewerPageFragment.kt @ragunathjawahar / legacycode.com
20. Eureka + StoryViewerPageFragment.kt @ragunathjawahar / legacycode.com
21. Eureka + StoryViewerPageFragment.kt (1350 LOC) @ragunathjawahar / legacycode.com
22. Live Demo 🧑💻 @ragunathjawahar / legacycode.com
23. Do • Use IDE-assisted refactoring • Use a git GUI client • Use micro-commits with Arlo Belshee’s commit notation • Pair/ensemble program • Verify manually
24. Don’t • Have long running branches • Push it too far @ragunathjawahar / legacycode.com
25. Installation $ brew install legacycodehq/tap/eureka @ragunathjawahar / legacycode.com
26. Watch $ eureka watch -x android StoryViewerPageFragment @ragunathjawahar / legacycode.com
27. @ragunathjawahar / legacycode.com
28. https://github.com/ LegacyCodeHQ/eureka @ragunathjawahar / legacycode.com
29. Questions? @ragunathjawahar / legacycode.com