Codemania - Coupling, Cohesion, Connascence

or One weird trick for better code

Transcript

1. Coupling, Cohesion, Connascence
2. I’m Josh @josh_robb Yada yada, Pushpay, we’re hiring etc...
3. making better design choices writing code
4. making better design choices writing code
5. better code
6. The way we think about software design is all wrong
7. A Grand Unified Theory of Software Design
8. reviewing code is hard
10. Am I a terrible programmer? • Start coding • [typing...] • this is easy I’ll just... • ... • 4 hours later • ... • FML - I SUCK
11. Good Design!
12. But What is Good Design?
13. Pragmatic Definition: “Programmers can add features steadily to well-designed software.” Kent Beck
16. What is Good Design? Simplicity Modularity Loose Coupling Can understand one piece without understanding others Design Patterns SOLID
17. Why does good design seem so hard?
18. 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
19. What is Good Design? 3 Ideas: • SOLID • Coupling and Cohesion • Connascence
20. SOLID 1996 (or 2000 for name)
21. SOLID Principles Single Responsibility Principle Open/Closed principle Liskov substitution principle Interface segregation principle Dependency Inversion principle
22. SOLID SOLID Deconstructed Kevlin Henney http://yow.eventer.com/yow-2013-1080/the-solid-design-principles-deconstructed-by-kevlin-henney-1386
23. SOLID - Recap Single Reason to Change Principle
24. Who has violated a SOLID principle this week?
25. SOLID Principles SOLID is a useful didactic tool but a useless decision making tool. Josh Robb (2014)
26. SOLID Principles TOO ABSTRACT/High Level How do I write: • this line of code? • this method • this class • this feature?
27. SOLID SUCKS
29. 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
30. Coupling + Cohesion 1972
31. Cohesion “Attempting to divide a cohesive module would only result in increased coupling and decreased readability.” Larry Constantine
32. Cohesion by contrast Adhesion / Adhesive - sticky thing Cohesion is the opposite
34. Code should actually represent the idea it names.
35. Adhesive Code public interface IHumungousMonolithicDataService { ... 33 methods dealing with ... approximately 18 difference concerns }
36. public interface IHumungousMonolithicDataService { #region Querying Stuff CardPayment GetCardPayment(Party party, int transactionId); Result<CardPayment> GetLastCardPayment(Party recipient, Person payer); IEnumerable<Merchant> SearchMerchants(GeoLocation currentCoordinate, Country country, int skip = 0, int take = 20); IEnumerable<Merchant> SearchMerchants(string name, Country userCountry, int skip = 0, int take = 20); IEnumerable<Merchant> GetMerchantRecommendationsForPerson(Person person, int skip = 0, int take = 20); Merchant GetMerchant(int merchantId, bool includeClosed = false); Merchant GetMerchantFromHandle(string handle); Merchant GetMerchantFromIdOrHandle(string idOrHandle); IEnumerable<ReferenceDefinition> GetReferenceDefinitions(Merchant merchant, bool includeRemoved = false); Person GetPerson(int personId); IEnumerable<Merchant> GetPersonsFavouriteMerchants(Person person, int skip = 0, int take = 50); GeoLocation GetPersonsLastKnownLocation(Person person); IEnumerable<Merchant> GetRecipientsForPayer(Person person); void CreateOrUpdatePushpayer(Person person, PushpayerAccountStatus status, int activityScore); #endregion // Huh? void Detach(Entity entity); #region Pushpayer Registration Stuff CreateCustomerResult BeginRegistration(CreateCustomerModel model); void CompleteRegistration(Person person, RegisterSource unknown); RegisterInfoResult RegisterInfo(Guid authToken, RegisterInfoModel info); Result MergeRegistrationWithExistingPerson(Guid registrationToken, Guid authToken); #endregion #region Pushpayer-Admin Own Account Result<MerchantPersonRelationship> AddFavourite(Person person, Merchant merchant); Result<MerchantPersonRelationship> RemoveFavourite(Person person, Merchant merchant); #endregion #region UserLogin / Auth / Security LoginResult Login(string username, string password); SessionToken Authenticate(Guid authToken); LoginResult LoginWeb(string username, string password); Result<SessionToken> AuthenticateWeb(Guid webToken); Result<SessionToken> ValidateSession(Guid sessionToken, SessionType sessionType = SessionType.App); Result<Guid> SendForgotPassword(string email); bool ValidatePasswordResetToken(Guid webToken); bool ResetPassword(Guid webToken, string password); void Logout(Person person, SessionToken sessionToken = null); void FreezeAccount(Person person); #endregion #region Merchant-Admin Own Account Result<MerchantAccountUpdateResultCode> UpdateMerchantInformation(MerchantAccountUpdateModel model, Merchant merchant); Result<MerchantControlTransferResultCode, Merchant> TransferMerchantAdmin(MerchantControlTransferModel model, Merchant merchant); #endregion }
37. Cohesion by contrast “Cohesion is the act of forming a united whole.”
38. Cohesive. Coupling? public interface IPushpayerPaymentService { PaymentResult CompleteWebPayment(PaymentInfo info, PaymentEvidence evidence); GuestPaymentResult CompleteGuestPayment(PaymentInfo info, PaymentEvidence evidence); PaymentResult CompleteMobileApiPayment(PaymentInfo info, PaymentEvidence evidence); }
39. Coupling? _cowabungaPipelineService = new PaymentCowabungaPipelineService( _gatewayServiceFactory.Object, _paymentDuplicationChecker.Object, _paymentQueryService.Object, _auditLoggerService.Object, _anticipatedPaymentsService.Object, _checkGatewayDebitPaymentSubmissionService.Object, _achPaymentViaPipelineService.Object, _paymentMethodEditingService.Object, _eventDispatcher.Object, _webhooksService.Object, _paymentNotificationService.Object, _mailService.Object, _supportMailService.Object, _minionCommander.Object, _authenticatedDeviceService.Object, _cardGatewayConfigurationConsultant.Object, _fieldUIService.Object, _validationService.Object); WAT WAT WAT WAT FML
40. “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
41. Connascence 1992
42. “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
44. Grand Unified Theory of Software Design
45. 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.
46. Connascence Connascence is a software quality metric [...] to allow reasoning about the complexity caused by coupling
47. “[...] because it classifies the relative strength of that coupling, connascence can be used as a tool to help prioritise what should be refactored first.” Kevin Rutherford http://silkandspinach.net/2015/01/22/connascence-of-value/ Connascence
48. Connascence Two software components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.
49. Connascence helps you safely anticipate change
50. Types of Connascence • Name • Type • Meaning • Position • Algorithm • Execution • Timing • Value • Identity
51. Strength/Degree • Name • Type • Meaning • Position • Algorithm • Execution • Timing • Value • Identity Weaker Stronger Degree Few occurrences Many occurrences
52. Static • Name • Type • Meaning • Position • Algorithm Types of Connascence Dynamic • Execution • Timing • Value • Identity
53. Con of Name class Customer { int Age {get;set} } var customer = new Customer(); customer.Age = 27;
54. Con of Name class Customer { int Age {get;set} } var customer = new Customer(); customer.Age = 27;
55. Con of Name “Doesn’t R# fix this?” (or IDEA or Eclipse #lolwat) Well - yes - thats the point - it’s the weakest
57. Con of Name The Best Connascence (tm) Sometimes
58. Con of Name ALTER TABLE Customer ALTER COLUMN Age INT NOT NULL; class Customer { string Age {get;set} } LOCALITY MATTERS
59. Rule of Locality Good - Within a method Bad - Between libraries
60. Rule of Locality Strong Weak
61. Con of Type Multiple components must agree on type.
62. Con of Type Multiple components must agree on type. function sayHello(name) { return "hello " + name; } var i = 0; console.log(sayHello(i));
63. Con of Type Maybe - your compiler (if you have one) will catch this - Maybe not.
64. Con of Type CREATE TABLE Payments (Amount int); class Payment { decimal Amount {get;set;} } RUH ROH
65. Con of Meaning Multiple places must agree on interpretation of values. e.g.
66. Con of Meaning Other examples:
67. Con of Meaning var result = GetTheThing(); if(result == null) //thing does not exist
68. Con of Meaning var result = GetTheThing(); if(result == Thing.DoesNotExist) //thing does not exist
69. Con of Meaning var result = GetTheThing(); if(result == string.Empty) //thing does not exist
70. Con of Meaning if(card.Number == “4111111111111111”) //test card
71. Con of Meaning if(card.Number.IsTestCard()) //test card
72. Con of Meaning payment.Amount == 41.11; //what unit/currency is this? The compiler isn’t going to help me here
73. Con of Meaning payment.Amount == new Money(41.11,Currency.USD); //Con of Type now
74. Con of Position void Save(string name, string address); myrerepo.Save(“bob”,“jamaica”); 2 Degrees of Connascence
75. Con of Position void Save(string firstname, string lastname,string address); myrerepo.Save(“bob”,“jamaica”);
76. Con of Position void Save(string name, string address1, string address2, string city, string country, string zip); myrerepo.Save(“bob”,“11 St”,“Suburb”,“Kingston”, “Jamaica”,“00234”,); 6 Degrees of Connascence
77. Con of Position -> Name/Type class User { FirstName, LastName, Address } void Save(User); myrerepo.Save(new User { FirstName = “bob”, LastName = “marley”, Address = “jamaica”});
78. Con of Position var things = [“one”,11.2,{a:1}] var amount = things[1];
79. Con of Algorithm Two or more places must agree on a particular algorithm.
80. Con of Algorithm var mobileNumber = GetMobileNo(); if(IsValidMobile(mobileNumber)) Particularly tricky with Javascript/server side transitions, crypto, interop/integration
81. Con of Algorithm Everyday example: Routing and Views.
82. Con of Algorithm Routes Map: Url -> Controller/Action /login -> AuthController.Login() Views Generate Url. <a href=”/login”>Log In</a>
83. Con of Algorithm ASP.NET MVC kinda gets this right by transforming Con of Algorithm -> Con of Meaning (Action/Controller name strings).
84. Static vs Dynamic No time for the details • Execution (order matters) • Timing (timing matters) • Value (related sets of values) • Identity (GetHashCode/UnitofWork)
85. Con of Value several values must change together.
86. Con of Value class Blog { public BlogStatus Status = BlogStatus.Draft; } public testBlog() { var blog = new Blog(); Assert.Equal(blog.Status == BlogStatus.Draft); }
87. Within a module we expect more connascence (both strength and degree)
88. Lowering connascence between modules makes things more cohesive
89. Ease of Change Name of a type <-- easy Name of a method <-- easy parameters of a method/type <-- harder contract of a method <-- hard.
90. One weird trick for better code
91. A grand unified theory of software design
92. Connascence
93. Thanks • Rob Fonseca-Ensor • Alex Henderson • Jim Weirich • Hamilton de Oliveira • Ward Cunningham • Sandi Metz • Gary Bernhardt • Corey Haines
94. Things 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