The author equates coupling with binding and dependence. (This is what is sometimes called tight coupling.) But he then defines cohesion as equivalent to what most people in the trade would call loose coupling - independence, with integration achieved through "logical agreement" (presumably some form of contract).
The standard notion of cohesion is quite different from this. It refers to the internal interdependence within a module. Way back in the days of modular programming, we were taught to decompose problems to achieve high cohesion (within modules) and low coupling (between modules). These concepts remain absolutely valid for web services and application integration.
Designers and architects operating within the latest technological context need to use new techniques of clustering and stratification to achieve the ancient goals of high cohesion and low coupling. Among other things, this provides a strategy for managing complexity, through the careful design and implementation of (service-based) interfaces between systems/subsystems.
Obviously there are contexts where the decomposition is given or constrained (by a higher level specification or by existing assets) - and the developer or integrator must simply build something efficient yet flexible against an unyielding interface. But the higher level architectural challenge - perhaps progressively over time - is to refine the decomposition and produce new cleaner interfaces to improve the architectural characteristics of the whole (loosely coupled) system.
No comments:
Post a Comment