많은 사람들이 두 개념을 서로 상반되는 의미로 설명하거나 이해하고 있는 것 같다. 모 책에서 같은 의미인데 다른 용어로 설명하는 것처럼 써놨더라... 두 용어에 대해 별로 깊게 생각해 본 사람이 아닌 것 같다. 실제로도 low coupling을 실현한다고 high cohesion이 되는 것은 아니다. 반대로도 마찬가지이고.
예를 들어보면, 모든 기능들을 하나의 module에 구현할 수 있을 것이다. 이 때 coupling은 0 (zero)가 되지만, cohesion 역시 낮아진다. 이처럼 두 개념은 조금만 생각해보면 서로 다른 것이다.
High cohesion 은 하나의 모듈이 단일 기능(unique function)을 구현해야 한다는 것이다. 예를 들어서 stack을 구현하는 모듈이 있다고 하자. 만약 스택에서 내부적으로 remote server에 접속해서 로그를 남기는 등의 기능을 수행한다면 이는 좋은 모듈이 아닐 것이다. 따라서 모듈은 그 자체로 cohesive한 function을 제공해야 한다.
Low coupling 은 모듈과 모듈 사이의 입장에서 보는 시각으로써, 두 모듈 간에는 서로 관련이 적어야 한다는 것이다. 모듈 사이에 결합이 전혀 없을 수는 없기 때문에, 이를 최소한으로 해야한다는 원칙이다. 모듈들 간에 서로의 design decision을 몰라야 된다는 말이 되겠다. 만약 모듈과 모듈이 tightly bound 된 상태라면 이는 readability를 감소시킬 수 있다. 즉, 하나의 모듈을 이해하기 위해서 다른 모듈들 까지 살펴봐야 한다. 또한 하나의 변경이 다른 부분에 영향을 줄 수도 있다. 모듈의 재사용이 어려워지고 유지보수하기 어려워진다. Low coupling을 실현하기 위해서, concrete한 것보다 abstract한 것에 의존하는 것이 좋다. 이 말은 interface라던가 abstract class처럼 잘 바뀌지 않는 부분에 의존하여 구현해야 한다는 말이다.
아래는 wikipedia에서 발췌한 내용이다.
High cohesion
Low couplingCohesion is a measure of how strongly-related and focused the responsibilities of a single class are. In object-oriented programming, if the methods that serve the given class tend to be similar in many aspects the class is said to have high cohesion. In a highly-cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable.
Cohesion is decreased if:
- The responsibilities (methods) of a class have little in common.
- Methods carry out many varied activities, often using coarsely-grained or unrelated sets of data.
Disadvantages of low cohesion (or "weak cohesion") are:
- Increased difficulty in understanding modules.
- Increased difficulty in maintaining a system, because logical changes in the domain affect multiple modules, and because changes in one module require changes in related modules.
- Increased difficulty in reusing a module because most applications won’t need the random set of operations provided by a module.
Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation (see Information Hiding). With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability.
Systems that do not exhibit low coupling might experience the following developmental difficulties:
- Change in one module forces a ripple of changes in other modules.
- Modules are difficult to understand in isolation.
- Modules are difficult to reuse or test because dependent modules must be included.
The concept of coupling is usually related to the concept of cohesion: low coupling facilitates high cohesion, and vice versa. For example, one approach to increasing cohesion is functional design, which seeks to limit the responsibilities of modules along functionally-related boundaries. Modules with single responsibilities tend to communicate less with other modules, which typically causes the side-effect of reduced coupling. This can also be seen in object-oriented programming, where coherence is said to increase when classes are re-factored to contain more closely-related code. This tends to cause the connections between the classes to become less dependent on their internal implementations, which results in reduced coupling. Specifically, coupling increases between two classes A and B if:
- A has an attribute that refers to (is of type) B.
- A calls on services of an object B.
- A has a method which references B (via return type or parameter).
- A is a subclass of (or implements) class B.
Low coupling may also reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Regardless, in many modern computing systems, the cost of reduced performance is often seen as a worthy trade for the benefits to the software development process that result from low coupling.[citation needed]
이올린에 북마크하기
