![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; }
}](https://image.slidesharecdn.com/design1couplingandcohesion-160630141541/85/Software-Design-1-Coupling-cohesion-10-320.jpg)
![class A {
private B b;
[..]
public void m() {
b.doYourJob();
}
}
class B {
private int x, y, z;
void doYourJob() {
z = x + y;
}
}](https://image.slidesharecdn.com/design1couplingandcohesion-160630141541/85/Software-Design-1-Coupling-cohesion-11-320.jpg)
![class A {
private F1 f1;
private F2 f1;
public void m1() {
[...]
f1.m();
}
public void m2() {
[...]
f2.m();
}
}](https://image.slidesharecdn.com/design1couplingandcohesion-160630141541/85/Software-Design-1-Coupling-cohesion-18-320.jpg)
![class A {
private F1 f1;
private F2 f1;
public void m1() {
[...]
f1.m();
}
public void m2() {
[...]
f2.m();
}
}](https://image.slidesharecdn.com/design1couplingandcohesion-160630141541/85/Software-Design-1-Coupling-cohesion-19-320.jpg)
Software Design 1: Coupling & cohesion
- 1. Software Design Coupling and Cohesion Attila Magyar Microsec Ltd. 2016
- 2. 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
- 3. 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
- 4. 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
- 5. Coupling and Cohesion (1979)
- 6. Coupling A B
- 7. Coupling
- 9. 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
- 10. 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; } }
- 11. class A { private B b; [..] public void m() { b.doYourJob(); } } class B { private int x, y, z; void doYourJob() { z = x + y; } }
- 12. 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
- 13. 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.
- 14. Cohesion
- 15. Cohesion
- 16. Types of cohesion Coincidental cohesion (worst) Logical cohesion Procedural cohesion Communicational/informational cohesion Sequential cohesion Functional cohesion (best)
- 17. LCOM1, LCOM2 & LCOM3 LCOM1 = Number of pairs of methods that do not share attributes M1 I3I1 I2 M2 M3 M4
- 18. class A { private F1 f1; private F2 f1; public void m1() { [...] f1.m(); } public void m2() { [...] f2.m(); } }
- 19. class A { private F1 f1; private F2 f1; public void m1() { [...] f1.m(); } public void m2() { [...] f2.m(); } }
- 20. 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
- 21. Summary Low coupling between modules High cohesion inside modules Things that change together are packaged together (CCP). Cohesion = Coupling but with different locality?
- 22. 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