'커플 링이 낮고 응집력이 높다'는 것은

'커플 링이 낮고 응집력이 높다'는 것은

---

나는 그 진술을 이해하는데 문제가있다 low in coupling and high in cohesion. 나는 구글에 대해 이것에 대해 많이 읽었지만 여전히 이해하기 어렵다.

내가 이해 High cohesion하는 것은 특정 기능을 수행하는 데 특화된 클래스가 있어야한다는 것을 의미합니다. 이것이 맞기를 바랍니다. 신용 카드 만 검증하는 신용 ​​카드 검증 클래스와 같습니다.

그리고 여전히 낮은 커플 링이 무엇을 의미하는지 이해하지 못합니까?

---

내가 믿는 것은 이것입니다 :

응집력은 모듈 / 클래스의 요소가 서로 속하는 정도를 말하며 관련 코드는 서로 가까이 있어야하므로 높은 응집력을 위해 노력하고 모든 관련 코드를 가능한 한 가깝게 묶어야합니다. 모듈 / 클래스 내의 요소와 관련이 있습니다.

커플 링은 서로 다른 모듈 / 클래스가 서로 의존하는 정도를 나타내며, 모든 모듈이 가능한 한 독립적이어야하므로 커플 링이 낮습니다. 다른 모듈 / 클래스 간의 요소와 관련이 있습니다.

전체 그림을 시각화하는 것이 도움이 될 것입니다.

스크린 샷은 Coursera 에서 가져 왔습니다 .

---

실제와 마찬가지로 소프트웨어 엔지니어링의 응집력 은 전체를 구성하는 요소 (우리의 경우 클래스를 말합시다)가 실제로 함께 속해 있다고 말할 수있는 정도입니다. 따라서 소프트웨어 모듈의 소스 코드로 표현 된 각 기능이 얼마나 밀접하게 관련되어 있는지를 측정 한 것입니다.

OO와 관련하여 응집력을 보는 한 가지 방법은 클래스의 메소드가 개인 속성을 사용하는 경우입니다.

이제 논의는 이것보다 더 크지 만 High Cohesion (또는 응집력이 가장 좋은 유형-기능적 응집력)은 모듈의 일부가 그룹화되어있을 때 모듈의 단일 정의 된 작업에 기여하기 때문입니다.

간단한 단어로의 결합 은 한 구성 요소가 (필수는 아니지만 클래스를 상상할 필요가 있음) 다른 구성 요소의 내부 작동 또는 내부 요소에 대해 얼마나 많이 알고 있는지, 즉 다른 구성 요소에 대한 지식이 얼마나 많은지입니다.

느슨한 결합 은 시스템 또는 네트워크에서 구성 요소를 상호 연결하여 해당 구성 요소가 실제로 가능한 한 최소한으로 서로 종속되도록하는 방법입니다.

나는 이것에 관한 블로그 게시물을 썼다 . 예제 등을 통해이 모든 내용에 대해 자세히 설명합니다. 또한 이러한 원칙을 따라야하는 이유의 이점도 설명합니다.

---

소프트웨어 디자인에서 높은 응집력 은 클래스가 한 가지 일을 잘 수행해야 함을 의미합니다. 높은 응집력은 단일 책임 원칙 과 밀접한 관련이 있습니다.

낮은 커플 링 은 클래스가 가능한 최소한의 종속성을 가져야 함을 나타냅니다. 또한 존재해야하는 종속성은 약한 종속성이어야합니다. 구체적인 클래스에 대한 종속성보다는 인터페이스에 대한 종속성을 선호하거나 상속보다 구성을 선호해야합니다.

높은 응집력과 낮은 결합은 유지하기 쉬운 더 나은 코드를 제공합니다.

---

낮은 커플 링은 두 개 또는 많은 모듈과 관련이 있습니다. 한 모듈의 변경으로 인해 다른 모듈에서 많은 변경이 발생하면 서로 관련이 있다고합니다. 인터페이스 기반 프로그래밍이 도움이됩니다. 모듈 간의 인터페이스 (상호 작용 평균)가 변경되지 않았으므로 모듈 내의 변경 사항은 다른 모듈에 영향을 미치지 않습니다.

높은 응집력-비슷한 것들을 함께 모으십시오. 따라서 클래스에는 관련 작업을 수행하는 메소드 또는 동작이 있어야합니다. 과장된 나쁜 예를 들기 위해 : List 인터페이스의 구현에는 String과 관련된 작업이 없어야합니다. String 클래스는 String과 관련된 메소드와 필드를 가져야하며 마찬가지로 List 구현에는 해당하는 것이 있어야합니다.

희망이 도움이됩니다.

---

짧고 명확한 답변

• 높은 응집력 : 하나의 클래스 / 모듈 내의 요소는 기능적으로 함께 속해 있어야하며 하나의 특정 작업을 수행해야합니다.
• 느슨한 결합 : 서로 다른 클래스 / 모듈 중에서 최소한의 종속성이 있어야합니다.

---

이해하기 쉬운 긴 이야기 짧고 낮은 커플 링은 시스템의 올바른 기능에 영향을 미치지 않고 구성 요소를 교체 할 수 있음을 의미했습니다. 기본적으로 시스템을 손상시키지 않고 개별적으로 업데이트 할 수있는 기능적인 구성 요소로 시스템을 변조

---

스마트 폰 있어요? 하나의 큰 앱이나 많은 작은 앱이 있습니까? 한 앱이 다른 앱에 응답합니까? 다른 앱을 설치, 업데이트 및 / 또는 제거하는 동안 하나의 앱을 사용할 수 있습니까? 각 앱이 자체 포함되어 있다는 것은 높은 응집력입니다. 각 앱이 다른 앱과 독립적이라는 것은 낮은 커플 링입니다. DevOps는이 아키텍처를 선호합니다. 즉, 시스템 전체를 방해하지 않고 개별 연속 배포를 수행 할 수 있기 때문입니다.

---

낮은 결합 및 높은 응집력은 권장되는 현상입니다.

커플 링은 다양한 모듈이 어느 정도 상호 의존적이며 다른 모듈이 모듈의 일부 / 상당한 기능 변경에 어떤 영향을 미치는지를 의미합니다. 의존성이 낮게 유지되어야하므로 다른 커플 링에 대해 최소한의 / 최소한의 변경이 이루어 지므로 낮은 결합이 강조된다.

---

예가 도움이 될 수 있습니다. 데이터를 생성하여 디스크 나 데이터베이스의 파일 인 데이터 저장소에 넣는 시스템을 상상해보십시오.

데이터 저장소 코드와 데이터 생산 코드를 분리하여 높은 응집력을 달성 할 수 있습니다. (실제로 데이터베이스 스토리지에서 디스크 스토리지를 분리).

데이터 생성에 데이터 저장소에 대한 불필요한 지식이 없는지 확인하여 낮은 커플 링을 달성 할 수 있습니다 (예 : 데이터 저장소에 파일 이름 또는 db 연결에 대해 묻지 않음).

---

Inheritance or generalization is an example of high coupling (i.e. high interdependence). What I meant by this is that in inheritance often the parent class defines base functionalities that is used by its child class and change in methods of parent class directly impact its child classes. Hence we can say that there is a greater degree of interdependence between classes.

Realization or using interface is an example of high cohesion (i.e. low interdependence). What this means is that an interface put forward a contract for any class that implements it but each class has the right to implement methods declared in interface in its own way and changes in method declared in one class doesn't affect any other class.

---

Here is an answer from a bit of an abstract, graph theoretic angle:

Let's simplify the problem by only looking at (directed) dependency graphs between stateful objects.

An extremely simple answer can be illustrated by considering two limiting cases of dependency graphs:

The 1st limiting case: a cluster graphs .

A cluster graph is the most perfect realisation of a high cohesion and low coupling (given a set of cluster sizes) dependency graph.

The dependence between clusters is maximal (fully connected), and inter cluster dependence is minimal (zero).

This is an abstract illustration of the answer in one of the limiting cases.

The 2nd limiting case is a fully connected graph, where everything depends on everything.

Reality is somewhere in between, the closer to the cluster graph the better, in my humble understanding.

From another point of view: when looking at a directed dependency graph, ideally it should be acyclic, if not then cycles form the smallest clusters/components.

One step up/down the hierarchy corresponds to "one instance" of loose coupling, tight cohesion in a software but it is possible to view this loose coupling/tight cohesion principle as a repeating phenomena at different depths of an acyclic directed graph (or on one of its spanning tree's).

Such decomposition of a system into a hierarchy helps to beat exponential complexity (say each cluster has 10 elements). Then at 6 layers it's already 1 million objects:

10 clusters form 1 supercluster, 10 superclusters form 1 hypercluster and so on ... without the concept of tight cohesion, loose coupling, such a hierarchical architecture would not be possible.

So this might be the real importance of the story and not just the high cohesion low coupling within two layers only. The real importance becomes clear when considering higher level abstractions and their interactions.

---

Cohesion - how closely related everything is with one another.
Coupling - how everything is connected to one another.

Let's take an example - We want to design a self-driving car.

(1) We need the motor to run properly.

(2) We need the car to drive on its own.

All of the classes and functions in (1) starting the motor and making it run work great together, but do not help the car steer. So we place those classes behind an Engine Controller.

All of the classes and functions in (2) work great to make the car steer, accelerate and brake. They do not help the car start or send gasoline to the pistons. So we place these classes behind its own Driving Controller.

These controllers are used to communicate with all of the classes and functions that are available. The controllers then communicate only with each other. This means I can't call a function in the piston class from the gas pedal class to make the car go faster.

페달 클래스는 구동 컨트롤러에게 엔진 컨트롤러와 통신하도록 요청한 다음 피스톤 클래스에 더 빨리 가도록 지시해야합니다. 이를 통해 프로그래머는 문제를 찾을 수 있으며 걱정없이 큰 프로그램을 결합 할 수 있습니다. 코드가 컨트롤러 뒤에서 모두 작동했기 때문입니다.

참고 URL : https://stackoverflow.com/questions/14000762/what-does-low-in-coupling-and-high-in-cohesion-mean