Coupling, Cohesion, Connascence

making better design choices writing code

Transcript

1. Coupling, Cohesion, Connascence
2. making better design choices writing code
3. I’m Josh @josh_robb Yada yada, Pushpay, we’re hiring etc...
4. The Plan Design? What is it? What is good design? A look at two old ideas One more old idea. Wrap up
5. Thanks • Ward Cunningham • Sandi Metz • Gary Bernhardt • Corey Haines
6. What is Design? ? Anyone?
7. What is Good Design?
9. What is Good Design? Simplicity? Modularity? SOLID? Loosely Coupled/High Cohesion Can understand 1 piece without understanding others.
10. Pragmatic Definition: “Programmers can add features steadily to well-designed software.” Kent Beck
11. Responsive Design “The more experience a programmer has, the more design ideas he knows. The temptation is to put these design ideas in the system now because you just know you’ll need them eventually. http://pragprog.com/magazines/2009-09/responsive-design
12. Responsive Design “The more experience a programmer has, the more design ideas he knows. The temptation is to put these design ideas in the system now because you just know you’ll need them eventually. http://pragprog.com/magazines/2009-09/responsive-design
13. Responsive Design “Over-designing early leads to delaying feedback from real usage of the system, makes adding features more complicated, and makes adapting the design more difficult.
14. Responsive Design “By the same token, under-designing makes adding features more complicated, increases defects, and makes adapting the design more difficult.
15. Responsive Design Some design needs to be done in advance of coding, but over the life of the project most design will be done in response to the changing needs of the system and the changing and growing understanding of the developers.”
16. What is Good Design? 3 Ideas: • Coupling and Cohesion • SOLID • Connascence
17. Coupling + Cohesion 1972
18. Cohesion “Attempting to divide a cohesive module would only result in increased coupling and decreased readability.”
19. Cohesion by contrast Cohesion/adhesion <- adhesive - sticky thing
20. Adhesion
22. Cohesion by contrast “Cohesion is a mutual relationship, with two things sticking together.”
24. Cohesion “Cohesion – that is to say, code should actually represent the idea it names.
25. Coupling “In a very real sense, isolated testing done test-first exposes design mistakes before they're made. It translates coupling distributed throughout the module into mock setup centralized in the test, and it does that before the coupling is even written down.” Gary Bernhardt
26. Coupling? Looks good to me!
27. Coupling?
28. “Mock setup exposes coupling, remember; not cohesion or other design properties.” Gary (again) Read the whole thing! https://www.destroyallsoftware.com/blog/2014/test-isolation-is-about-avoiding- mocks Coupling
29. SOLID 1996 (or 2000 for name)
30. SOLID Principles Single Responsibility Principle Open/Closed principle Liskov substitution principle Interface segregation principle Dependency Inversion principle
31. SOLID Principles TOO ABSTRACT/High Level How do I write: this line of code? this method this class this feature?
32. SOLID Principles SOLID is a useful didactic tool but a useless decision making tool. Josh Robb (right now)
33. SOLID SOLID Deconstructed Kevlin Henney http://yow.eventer.com/yow-2013-1080/the-solid-design-principles-deconstructed-by-kevlin-henney-1386
34. SOLID Principles Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
35. SOLID Principles Single Responsibility Principle: a class should have only a single responsibility Wikipedia
36. SOLID Principles Single Responsibility Principle: a class should have only a single responsibility Wikipedia
37. SOLID Principles Single Reason to Change principle There should never be more than one reason for a class to change Uncle Bob
38. SOLID Principles Open/Closed principle “open for extension, closed for modification” aka. Single Reason to Change principle
39. SOLID Principles Interface segregation principle “Only use what you need” aka. Single Reason to Change principle
40. SOLID Principles Dependency Inversion principle “Depend upon abstractions” aka. Single Reason to Change principle
41. SOLID Principles Liskov Substitution Principle “Subtypes must not violate the contract of super types” aka. The exception
42. Liskov “What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T”
43. Liskov “What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T”
44. SOLID - Recap SOLID RIP.
45. SOLID - Recap Single Reason to Change Principle
46. SOLID - Recap
47. How do I anticipate change? You can’t! Trying to is a really bad mistake! “Duplication is far cheaper than the wrong abstraction” Sandi Metz
48. SOLID - Recap “In short: pop cultural ideas, such as testability, readability and elegance, are easy to follow but hard to communicate across observers. Then again, object-oriented design principles tend to be easy to communicate, but hard to follow.
49. SOLID - Recap “Internalizing the reason for failure easily drives them into a vicious loop of self-blame: “this should work, I’ve been told that SOLID/GRASP is a great idea, so it must be my fault that I don’t see how and why this still fails.”
50. Connacense 1992
51. “Comparing techniques by means of encapsulation and connascence” Communications of the ACM Special issue on analysis and modeling in software development CACM Volume 35 Issue 9, Sept. 1992
53. Connascence 1. The common birth of two or more at the same time; 2. That which is born or produced with another. 3. The act of growing together.
54. Connascence “Connascence is a software quality metric to allow reasoning about the complexity caused by dependency relationships in object oriented design”
55. Tries to answer design questions: e.g. “Prefer delegation over inheritance” But why does delegation introduce less coupling then inheritance.
56. Inheritance is evil? abstract class ProfileRequest { Profile Profile { get; set; } } class CreateProfileRequest : ProfileRequest {} class UpdateProfileRequest : ProfileRequest{ int ProfileId { get; set; } }
57. Inheritance is evil? “It's often best to wait a bit longer than is comfortable, hoping that tolerating interim duplication will produce code that gives you better information about the problem as a whole.
58. Inheritance is evil? “when you DRY out duplication, you're declaring that these two bits of identical code really do represent identical concepts. If you're wrong about this it can be very difficult to extend code later. - Sandi Metz
59. Inheritance is evil? "You'll never know less than you know right now"
60. Taxonomy
61. Taxonomy • Name • Position • Meaning • Algorithm • Type • Execution • Timing • Value • Identity • Degree • Locality • Stability Principles
62. Strength/Degree • Name • Position • Meaning • Algorithm • Type • Execution • Timing • Value • Identity Weaker Stronger Degree
63. Con of Name
64. Con of Name
65. Con of Name 2 Degrees of Connaissance
66. Con of Name “Doesn’t R# fix this?” (or IDEA or Eclipse #lolwat) Well - yes - thats the point - it’s the weakest
67. Con of Name The Best Connascence (tm)
69. Con of Position 2 Degrees of Connaissance
70. Con of Position 3 Degrees of Connaissance
71. Con of Position var things = [“one”,11.2,{a:1}] var amount = things[1]; 1 Degree of Connaissance
72. Con of Position -> Name
73. Con of Meaning Multiple places must agree on meaning of values. e.g.
74. Con of Meaning Other examples:
75. Con of Meaning
76. Con of Meaning
77. Con of Meaning
78. Con of Algorithm Two or more places must agree on a particular algorithm.
79. Con of Algorithm Particularly tricky with Javascript/server side transitions, crypto, interop/integration
80. Con of Algorithm Classic example: Routing and Views.
81. Con of Algorithm Routes Map: Url -> Controller/Action /login -> AuthController.Login() Views Generate Url. <a href=”/login”>Log In</a>
82. Con of Algorithm ASP.NET MVC kinda gets this right by transforming Con of Algorithm -> Con of Meaning (Action/Controller name strings).
83. Con of Type multiple components must agree on the type of an entity.
84. Con of Type //Do some stuff and finally ... EnforcePaymentStatusPolicy.Execute(blackboard);
85. Con of Type //Do some stuff and finally throw new Exception(); EnforcePaymentStatusPolicy.Execute(blackboard);
86. Con of Type
87. Con of Type using (EnforcePaymentStatusPolicy.Execute(blackboard)){ //Do some stuff and finally //herp derp }
88. Con of Type
89. Con of Type
90. Con of Type
91. Static vs Dynamic No time but Dynamic Connacense: • Execution (order matters) • Timing (timing matters) • Value (related sets of values) • Identity (GetHashCode/UnitofWork)
92. Locality within a module -> strong connascence between modules -> weak connascence
93. Determining Coupling Strong Coupling <-> Weak Connacense Weak Coupling <-> Weak Coupling
94. Ease of Changing Name of a type <-- easy Name of a method <-- easy parameters of a method/type <-- harder contract of a method <-- hard.
95. Decrease degree of connascence Increase locality of connascence
96. Evil Inheritance? class CreateProfileRequest : ProfileRequest {} void CreateProfile(CreateProfileRequest req); How many degrees/what type of Connaissance?
97. Evil Inheritance? class CreateProfileRequest : ProfileRequest {} void CreateProfile(CreateProfileRequest req); How many degrees/what type of Connaissance? Con of Type
98. Summary Design is Fractal. Design simply today, knowing you can add complexity needed tomorrow. No project ever failed because the design wasn’t complex enough
99. Talks you should watch http://yow.eventer.com/yow-2012-1012/connascence- examined-by-jim-weirich-1273 https://web.archive.org/web/20100124132104/http: //onestepback.org/articles/connascence/index.html http://www.confreaks.com/videos/3358-railsconf-all-the- little-things