Example: low cohesionĬodebases sometimes have a global utils module that is a drop box for miscellaneous code that doesn't fit elsewhere.
Next, we illustrate how to use these concepts in practice. Module m2 is less cohesive than m1, because it has only one intramodule relationship. Module m1 is not maximally cohesive, because it does not have the relationship between e2 and e3. To increase cohesion, we need to increase intramodule coupling. A maximally cohesive module has all possible intramodule relationships. This is often a desirable type of coupling.Ĭohesion of a module is defined using intramodule coupling. For module m1, these are the relationships from e1 to e2 and e1 to e3. Intramodule coupling of an individual module consists of the relationships between the elements of the module. This is the kind of coupling we often want to minimize.
In our example, these are the relationships from e4 to e1 and e5 to e3.
We define two distinct types of coupling, "bad" and "good", and define cohesion using "good" coupling.Ĭoupling of the entire system consists of the intermodule relationships. Element e5 is coupled to e3 from module m1. The second functionality consists of elements e5 and e6. The first, e4, invokes e1 using an intermodule (coupling) relationship. Module m2 consists of two unrelated functionalities. Intuitively, e1 might be the entry point of module m1 and it delegates functionality to e2 and e3 using intramodule relationships. This system consists of six elements (e1 to e6) which are grouped into two modules (m1 and m2). In order to formulate coupling and cohesion, we think of the system abstractly as a network of atomic elements (such as functions) and their relationships, and group elements into modules. But how are these concepts defined and how to apply them in practice? Is it a good idea to always minimize coupling and maximize cohesion? Framework: network of software elements Thus, it would appear, the programmer should follow the common advice "aim for low coupling and high cohesion". High coupling leads to unintended change cascades, and low cohesion leads to incomprehensible code. There can be relationships where they shouldn't exist (high coupling), or modules can be poorly divided so that unrelated functions are grouped together (low cohesion). Many structural code problems can be understood in terms of relationships between code units. The code is poorly organized, the purpose of a module is difficult to understand, and changing code in one place leads to unintended changes elsewhere. Often developers see code that is hard to read and maintain, but it's difficult to pinpoint why.
0 kommentar(er)
