Software Design 1: Coupling & cohesion

Software Design Coupling and Cohesion

Attila MagyarMicrosec Ltd.2016

Design goals Optimization for maintenance

Cost of change Adding new feature Fixing or modifying existing feature

Understandability How simple is it?

Robustness and correctness How hard is to break it? (code and execution)

Easy to change, easy to understand, hard to break

Design “principles”, guidelines, metrics SOLID by Michael Feathers and Robert C. Martin

LoD, Tell don’t Ask, Packaging Principles (CCP, CRP), etc 4 rules of simple design by Kent Beck Responsibility Driven Design by Rebecca Wirfs-Brock Test Driven Design (GOOS) by Freeman and Pryce The Physics of Software by Carlo Pescio Connascence by Meilir Page-Jones Cohesion and Coupling by Larry Constantine Code Smells Domain Driven Design by Eric Evans

Design principles, guidelines, metrics SOLID 4 rules of simple design (DRY) Responsibility Driven Design (Roles) Test Driven Design (GOOS) (Context

independence) The Physics of Software (Entanglement, Friction) Connascence by Meilir Page-Jones Code Smells (FE, Inappr. Intimacy, Message Chain,

Large class, Long Method, Long arg. list) Cohesion and Coupling by Larry Constantine

Coupling and Cohesion (1979)

Coupling

A B

Coupling

Reasons of coupling

DuplicationDependency

Types of Coupling Content coupling (high) Common coupling (also known as Global coupling) External coupling Control coupling Stamp coupling (Data-structured coupling) Data coupling Message coupling (low) No coupling

class A { private B b; [..] public void m() { b.setZ(b.getX() + b.getY()); }}

class B { private int x, y, z;

int getX() { return x; } int getY() { return y; } void setZ(int z) { this.z = z; }}

class A { private B b; [..] public void m() { b.doYourJob(); }}

class B { private int x, y, z;

void doYourJob() { z = x + y; }}

Benefits of low coupling

Benefits of low coupling Less ripple effect when changing code Modules are easier to reuse because they are less

context dependent Individual modules are easier to understand

Coupling between test and code Any assertion upon implementation details

Testing through non-public API Private method/field access

Overly constrain the protocols

Interaction testing does not cause fragility by itself. Don’t blame Mocks.

Cohesion

Cohesion

Types of cohesionCoincidental cohesion (worst)Logical cohesionProcedural cohesionCommunicational/informational

cohesionSequential cohesionFunctional cohesion (best)

LCOM1, LCOM2 & LCOM3

LCOM1 = Number of pairs of methods that do not share attributes

M1

I3I1 I2

M2 M3 M4

class A { private F1 f1; private F2 f1; public void m1() { [...] f1.m(); } public void m2() { [...] f2.m(); }}

class A { private F1 f1; private F2 f1; public void m1() { [...] f1.m(); } public void m2() { [...] f2.m(); }}

Low cohesion

Unrelated responsibilities/functions imply that the module will have unrelated reasons to change in the future

Replacing parts is difficult

Higher risk of breaking existing functionality when changing

Summary

Low coupling between modules High cohesion inside modules

Things that change together are packaged together (CCP).

Cohesion = Coupling but with different locality?

Food for thought Object Design: Roles, Responsibilities, and Collaborations

https://www.amazon.com/Object-Design-Roles-Responsibilities-Collaborations/dp/0201379430 Carlo Pescio — Software Design and the Physics of Software

https://www.youtube.com/watch?v=WPgYju3KnIY Growing Object-Oriented Software, Guided by Tests

https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 Jim Weirich - Connascence Examined

https://www.youtube.com/watch?v=HQXVKHoUQxY Understanding the Four Rules of Simple Design

https://leanpub.com/4rulesofsimpledesign Practical Object-Oriented Design in Ruby

https://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley-ebook/dp/B0096BYG7C

Smalltalk Best Practice Patterns https://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X