Content deleted Content added
→High/low coupling: +spaces |
merge from Low-Coupling / High-Cohesion pattern |
||
Line 1:
{{mergefrom|Low-Coupling / High-Cohesion pattern}}▼
In [[computer science]], '''coupling''' or '''dependency''' is the degree to which each program module relies on each other module.
Line 28 ⟶ 26:
Build systems like [[make]] are also dependency driven in the sense that a more complex object, like a [[Computer_program|program]], only gets [[Linker|linked]] together once all its dependencies, i.e. the objects it is built of, have been [[Compiler|compiled]].
In [[computer science]], the '''Low-Coupling / High-Cohesion''' isn't a specific [[pattern]] amongst [[design pattern (computing)|design pattern]]s. It's a general [[method]] for structuring [[Computer program|program]]s so that they're simpler to understand, program and maintain.
These concepts (Low-Coupling / High-Cohesion) are usually related. Low coupling implies high cohesion and viceversa, because if we put together all relationed methods (High Cohesion), the connection between classes tends to get lower (Low Coupling).
=== Low Coupling ===
Coupling is a measure of how strongly one class is connected to another and is increased between Class A and Class B when:
*A has an attribute that refers to (is of type) B.
*A calls on services of a B object.
*A has a method which references B (via return type or parameter).
*A is a subclass of (or implements) B.
The disadvantages of high coupling includes:
*A change in one class forces a ripple of changes in other classes.
*Difficult to understand a class in isolation.
*Difficult to reuse a class because dependent class must also be included.
=== High Cohesion ===
If we want to design classes to increase the likelihood of reuse and not be overwhelmingly complex, keeping complexity manageable, the solution is assigning responsibilities so that cohesion remains high.
Cohesion is a measure of how strongly related and focused the responsibilities of a single class are. Cohesion is decreased when:
*The responsibilities (operations) of a class have little in common.
*Operations do many varied activities, often using varied data.
The disadvantages of weak cohesion are:
*Difficult to understand.
*Difficult to maintain, because it is constantly affected by changes.
*Difficult to reuse a class because most application won’t need a random set of operations attached to a class.
=== Related patterns ===
Although low coupling is a desirable goal, and this goal provides useful guidance, the description of the pattern does not tell how to actually achieve low-coupled design in most cases. [[Functional design]] limits the responsibilities of modules. Modules with single responsibilities usually need to communicate less with other modules, and this has the virtuous side-effect of reducing coupling and increasing cohesion in many cases.
==See also==
Line 35 ⟶ 69:
[[Category:Object-oriented programming]]
[[Category:Software architecture]]
[[zh:接口模式]]
| |||