Cohesion: The Binding Force of Modules

Cohesion: The Binding Force of Modules

Cohesion is often used in software development, yet its essence can sometimes elude seasoned professionals. It measures how interconnected and dependent the elements within a module are on one another. The more cohesive a module, the tighter the bond between its components. However, this bond can also be a double-edged sword: splitting a highly cohesive module might lead to increased interdependencies and a drop in readability.

A Brief Glimpse into History

The term's significance was brought to the limelight by Larry Constantine. He emphasized that a truly cohesive module would defy beneficial fragmentation. Trying to segment it would only augment its complexity.

The Spectrum of Cohesion

There are only so many kinds of cohesion. Computer scientists have defined a gradation, categorized from the best to the most minor ideal:

  1. Functional Cohesion: A state where every module part is interrelated and encompasses everything vital for its function.
  2. Sequential Cohesion: It involves two modules where one's output becomes the input for the next.
  3. Communicational Cohesion: A communication chain forms between two modules, contributing to an output or working on shared data.
  4. Procedural Cohesion: A sequence is paramount. The order in which the modules run is critical.
  5. Temporal Cohesion: Modules are connected based on when they operate. Initialization at system start-up is a classic example.
  6. Logical Cohesion: The correlation is more in thought than function. An example would be a module that converts data in various ways.
  7. Coincidental Cohesion: This is the lowest rung, where the only connection is that the components reside in the same source file.

However, the waters of cohesion can be murky. What one architect might view as a cohesive unit, another could see as a candidate for further division. Such subjectiveness makes cohesive assessment less precise than, say, coupling.

For example, should 'get customer orders' and 'cancel customer orders' be part of a 'Customer Maintenance' module or separated into an 'Order Maintenance' module?

Customer Maintenance

  • add customer
  • update customer
  • get customer
  • notify customer

Order Maintenance

  • get customer orders
  • cancel customer orders

The decision requires a delicate balance and an analysis of factors like expected growth, knowledge requirements, and potential coupling.

The LCOM Metric

Even with its inherent subjectivity, metrics have been devised to gauge cohesion. The Chidamber and Kemerer, Object-oriented metrics suite is an ensemble that has gained significant traction. The Lack of Cohesion in Methods (LCOM) metric offers insights into a module/class structural cohesion within this suite.

  • LCOM = 1: The class is a solid component with all methods and fields related
  • LCOM > 1: The class can be split into different classes
  • LCOM = 0: The class has no methods


As shown in the diagram, the class contains two separate components and could be split into two classes: methods A and B and field x and methods C and D and fields y and z.

If method C invokes method A or B or accesses field x, the result is one connected component, and the class has an LCOM equal to 1

The beauty of the LCOM metric lies in its application. Software architects can utilize it when transitioning between architectural styles. It becomes a beacon, identifying classes that might have been accidentally coupled and should be segmented.

However, like all metrics, LCOM could be more flawless. It identifies structural cohesion but doesn't factor in logical cohesiveness. This is where human judgment and experience come into play, underscoring the importance of understanding the 'why' over the 'how.'

Conclusion

Cohesion is a central pillar in software architecture. Ensuring the right level of cohesion can lead to cleaner, more maintainable, and efficient code. As technology progresses and software paradigms evolve, the principles of cohesion will remain crucial, guiding architects and developers in creating robust and efficient systems.

References



要查看或添加评论,请登录

社区洞察

其他会员也浏览了