Java Coupling and Cohesion
- Introducing Coupling and Cohesion
- Packages as Units of Abstraction
- Ubiquitous Code
- Public and Private Packages
- Package Maintenance and Coupling
- Reflection and Package Coupling
- Conclusion
Introducing Coupling and Cohesion
Last month I described how the history of programming languages is one of gradually rising levels of abstraction. Machine instructions are grouped into expressions, chunks of code are grouped into structured programming structures, and chunks of data are grouped into classes. For a unita line of code, a method, a classto be easily maintainable, you want everything in it to be on a single topic, and only things on that topic are in that unit.
Generally, no matter what size the unit is, a designer should strive to decrease dependencies between units, while increasing the dependencies within a unit. When two units depend on each other, it's called coupling, and it's a bad thing. It means that you can't understand one unit without understanding the other, which makes maintenance difficult. It also means that you can't pick up one unit without the other, which makes it hard to reuse and maintain.