Slides used in: https://www.meetup.com/dotnetters/events/244837187/?eventId=244837187

1. SOLID
@alfredodev
afernandez@plainconcepts.com

2. SOLID
• Acronim of five principles
• Principles, not laws
• A bit vague or abstract
• They are all interelated
• A bit marketing oriented (ejem Uncle Bob ;) )
• A bit criticized
• By Michael Feathers or Robert Martin

3. Critics
• Simple code
• Testeable code
• Low cohesion high coupling

4. Critics
• Simple code
• Testeable code
• Low cohesion high coupling
• Low coupling high cohesion

5. @gerard_lopz @quiqu3
@alfredodev

6. @gerard_lopz @quiqu3
@alfredodev
SOLID!

8. https://github.com/joebew42/study-path

10. SOLID

11. Single
Responsibility
Principle

12. Single
Responsibility
Principle
A class should have only
one responsibility.
Each software module
should have one and only
one reason to change.

13. Single
Responsibility
Principle
What is a responsibility?

14. Single
Responsibility
Principle
What is a reason to
change?

15. Example 1

16. Cohesion
• Cohesion refers to the degree to which the elements inside a module
belong together

17. Cohesion
• Cohesion refers to the degree to which the elements inside a module
belong together

18. Responsibilities to whom?
• Classes have responsibilities to their users, those users can be
classified into actors based on the roles that they play on the
application.
• A responsibility is a family of functions that serves a particular actor.

19. Example 1
Support
Banking
Tinder?
IT / operations

20. Single
Responsibility
Principle
What about methods?

21. Example 2

22. Tips
• Describe what the class does in one sentece (did you use the word
and or or?)
• Please Mr Object what is your Property

23. What are your
thoughts?

24. SOLID

25. Open
Close
Principle

26. Open
Close
Principle
A software module should
be open for extension and
close for modification
Change a module
behaviour without
changing its source code

27. Examples

28. Related
• Encapsulation
• Abstraction
• Dependency Inversion

29. What are your
thoughts?

30. SOLID

31. Liskov
Substitution
Principle

32. Liskov
substitution
Principle
If S is a subtype of T, then objects of type T
may be replaced with objects of type S
If the base class does something, the
inherited class must do it too and in a way
that doesn't violate the expectations of the
users of the base class

33. Examples

34. Simptoms
• Inherited class with empty methods that are implemented in the base
class
• Inherited class with that throw exceptinos
• Check If typeof (x) on the base class

35. I’ve fucked up
Screen
SearchScreen
ComplexSearch SimpleSearch
MaintenanceScreen
SimpleMaintenance
TabbedMaintenance

36. I’ve fucked up
Screen
SearchScreen
ComplexSearch SimpleSearch
MaintenanceScreen
SimpleMaintenance
TabbedMaintenance
SpecialMaintenanceWithSearch

37. What about dynamic languages
• Dynamic languages are different
• Duck typing
• It’s harder but the same principles should apply

38. Tips
• Don’t have high hirerarchies of objects
• Favor composition over inheritance

39. What are your
thoughts?

40. SOLID

41. Interface
Segregation
Principle

42. Interface
Segregation
Principle
No client should be forced to depend
on methods it does not use
Interfaces have more to do with the
classes that use them than with the
classes that implement them

43. Examples

44. Depending on not used methods
• Forces you to recompile when those methods change
• Forces you to redeploy

45. Depending on not used methods
• Makes it harder to understand

46. Depending on not used methods
• Makes it harder to reuse
• Forces you to have empty mehods

47. What are your
thoughts?

48. SOLID

49. Dependency
Inversion
Principle

50. 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.

51. Dependency Injection

52. Inversion of control

53. 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.

54. Dependency Inversion

55. Dependency
Inversion
Principle
Should we abstract
everything?

57. SOLID
Should we make a milion
tiny classes?

58. https://www.youtube.com/watch?v=llGgO74uXMI
Core Design Principles for Software Developers by Venkat
Subramaniam

60. 4 rules of simple design
• Passes the tests
• Reveals intention
• No duplication
• Fewest elements

61. TRUE
• Transparent: The consequence of change should be obvious in the
code that is changing and in distant code that relies upon it
• Reasonable: The cost of any change should be proportional to the
benefits the change achieves
• Usable: The code should be usable in new and unexpected contexs
• Exemplary: The code itself should encourage those that use it to
perpetuate those qualities

64. Thank you!
Now questions! and more thoughts?
@alfredodev
afernandez@plainconcepts.com