Given two lines of code, A and B, they are coupled when B must change behavior only because A changed.
They are cohesive when a change to A allows B to change so that both add new value.The difference between CouplingAndCohesion is a distinction on a process of change, not a static analysis of code's quality. But there are plenty of indicators and BestPractices...These are some of the better-defined qualities that separate good software from bad software. Although they were formalized during the invention of StructuredProgramming, they apply exactly as well toObjectOrientedProgramming as to any other kind.Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.
They are cohesive when a change to A allows B to change so that both add new value.The difference between CouplingAndCohesion is a distinction on a process of change, not a static analysis of code's quality. But there are plenty of indicators and BestPractices...These are some of the better-defined qualities that separate good software from bad software. Although they were formalized during the invention of StructuredProgramming, they apply exactly as well toObjectOrientedProgramming as to any other kind.Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.
- Someone had vague reference to decomposability here. Clarification?
- How about: 'Cohesion is inversely proportional to the number of responsibilities a module/component has.'
- size: number of connections between routines
- intimacy: the directness of the connection between routines
- visibility: the prominence of the connection between routines
- flexibility: the ease of changing the connections between routines
- Coincidental Cohesion : (Worst) Module elements are unrelated
- Logical Cohesion : Elements perform similar activities as selected from outside module, i.e. by a flag that selects operation to perform (see also CommandObject).
- i.e. body of function is one huge if-else/switch on operation flag
- Temporal Cohesion : operations related only by general time performed (i.e. initialization() or FatalErrorShutdown?())
- Procedural Cohesion : Elements involved in different but sequential activities, each on different data (usually could be trivially split into multiple modules along linear sequence boundaries)
- Communicational Cohesion : unrelated operations except need same data or input
- Sequential Cohesion : operations on same data in significant order; output from one function is input to next (pipeline)
- Informational Cohesion: a module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure. Essentially an implementation of an abstract data type.
- i.e. define structure of sales_region_table and its operators: init_table(), update_table(), print_table()
- Functional Cohesion : all elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation
- get_engine_temperature(), add_sales_tax()
- Content/Pathological Coupling : (worst) When a module uses/alters data in another
- Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag)
- Common/Global-data Coupling : 2 modules communicating via global data
- Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs.
- Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs.
- No data coupling : independent modules.
