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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |