- Introducing Coupling and Cohesion
- Packages as Units of Abstraction
- Ubiquitous Code
- Public and Private Packages
- Package Maintenance and Coupling
- Reflection and Package Coupling
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Package Maintenance and Coupling
The original developers and designers establish an initial set of packages, and often these are loosely coupled and tightly cohesive. It's very easy for package coupling to increase during maintenance. It's often unplanned, but creeps into the code when one programmer connects two things just temporarily, to fix a bug—and never gets around to undoing it.
When you're maintaining a package, and need to make a reference to some other package, see whether connections to that package already exist. If your class is already inextricably coupled to the other package, you might as well increase the coupling. In the future, you may even combine the two packages into a single package, or make them sub-packages of a common root package. Then your coupling suddenly becomes coherence.
If there are no dependencies from the existing package to another package, look for another way to get the functionality you need. For example, it may be tempting in the server package to use the merge function in the Object3D class to merge two triangles. However, this introduces a coupling to the client package, which runs counter to some of our other goals. You have options:
Move the method into the server package, which is already coupled to the client.
Rewrite the method somewhere in the server package.
In this case, it's likely that the method really "belongs" as an object method on Triangle, rather than on the class, but you'd need to check your other uses of merge to find the best choice.
If there is only small coupling between packages, you have a choice. You can either take upon yourself the maintenance task of eliminating all the coupling, or just go ahead and increase it. Although we use the terms tight and loose coupling, in many ways there is either "coupled" or not. If you need exactly one static method in one class in the package, you're coupled to that package. For operations that operate at a package level, such as jar or javac, it doesn't really matter if there's a single connection or many. You have to jar up or compile the whole package, whether the coupling is tight or loose.