응집력과 커플 링의 차이점

응집력과 커플 링의 차이점

---

응집력과 커플 링의 차이점은 무엇입니까?

커플 링과 응집력은 어떻게 소프트웨어 설계를 좋거나 나쁘게 만들 수 있습니까?

이 둘의 차이점과 전반적인 코드 품질에 미치는 영향을 설명하는 몇 가지 예는 무엇입니까?

---

응집력 은 클래스 (또는 모듈)가 할 수있는 일을 말합니다. 응집력이 낮 으면 수업이 다양한 행동을 취한다는 것을 의미합니다. 응집력이 높다는 것은 수업이해야 할 일, 즉 수업의 의도와 관련된 방법에만 집중한다는 것을 의미합니다.

낮은 응집력의 예 :

-------------------
| Staff           |
-------------------
| checkEmail()    |
| sendEmail()     |
| emailValidate() |
| PrintLetter()   |
-------------------

높은 응집력의 예 :

----------------------------
| Staff                   |
----------------------------
| -salary                 |
| -emailAddr              |
----------------------------
| setSalary(newSalary)    |
| getSalary()             |
| setEmailAddr(newEmail)  |
| getEmailAddr()          |
----------------------------

관해서 결합 , 두 개의 클래스 / 모듈이 서로를 향해 얼마나 관련 또는 의존성을 의미한다. 낮은 결합 클래스의 경우 한 클래스에서 중요한 것을 변경하면 다른 클래스에 영향을 미치지 않아야합니다. 커플 링이 높으면 코드를 변경하고 유지하기가 어려워집니다. 클래스가 밀접하게 연결되어 있으므로 변경하려면 전체 시스템을 개선해야합니다.

좋은 소프트웨어 디자인은 높은 응집력 과 낮은 커플 링을 가지고 있습니다.

---

모듈 내에서의 높은 응집력 과 모듈 간의 낮은 결합 은 종종 OO 프로그래밍 언어에서 고품질과 관련된 것으로 간주됩니다.

예를 들어, 각 Java 클래스의 코드는 내부 응집력이 높아야하지만 다른 Java 클래스의 코드에 가능한 한 느슨하게 연결되어 있어야합니다.

Meyer의 객체 지향 소프트웨어 구성 (제 2 판) 3 장 에서는 이러한 문제에 대해 자세히 설명합니다.

---

응집력 은 모듈 내의 관계를 나타냅니다 .

커플 링 은 모듈 간의 관계 를 나타냅니다 .

응집력

• 응집력은 모듈 내의 관계를 나타냅니다.
• 응집력은 모듈의 상대적 기능 강도를 보여줍니다.
• 응집력은 구성 요소 / 모듈이 단일 것에 집중하는 정도 (품질)입니다.
• 설계하는 동안 시스템의 다른 모듈과의 상호 작용이 거의없는 단일 작업 (즉, 단일 사고)에 집중적 인 응집력있는 구성 요소 / 모듈 포커스를 위해 노력해야합니다.
• 응집력은 기본적으로 가시성을 가진 패키지로 모든 멤버를 볼 수있는 클래스 등 데이터 숨기기의 자연스러운 확장입니다. 응집력은 인트라 – 모듈 개념입니다.

커플 링

• 커플 링은 모듈 간의 관계를 나타냅니다.
• 커플 링은 모듈 간의 상대적 의존성 / 상호 의존성을 보여줍니다.
• 커플 링은 구성 요소 / 모듈이 다른 모듈에 연결되는 정도입니다.
• 설계하는 동안 낮은 커플 링을 위해 노력해야합니다. 즉 모듈 간의 종속성이 적어야합니다.
• 개인 필드, 개인 메소드 및 비 공용 클래스를 작성하면 느슨한 결합이 제공됩니다.
• 커플 링은 모듈 간 개념입니다.

이 링크를 확인

---

응집력 은 소프트웨어 요소의 책임이 얼마나 관련성이 있고 집중되어 있는지를 나타냅니다.

커플 링 은 소프트웨어 요소가 다른 요소에 얼마나 강력하게 연결되어 있는지를 나타냅니다.

소프트웨어 요소는 클래스, 패키지, 구성 요소, 서브 시스템 또는 시스템 일 수 있습니다. 시스템을 설계하면서 그리고이 소프트웨어 요소가하는 것이 좋습니다 높은 응집력 및 지원 낮은 커플 링을 .

응집력이 낮 으면 유지 보수, 이해 및 재사용이 어려운 모 놀리 식 클래스가 생성됩니다. 마찬가지로 High Coupling 은 밀접하게 결합 된 클래스를 생성하며 변경은 로컬이 아니고 변경이 어렵고 재사용이 감소하는 경향이 있습니다.

ConnectionPool다음 요구 사항으로 일반적인 모니터 가능 을 설계하는 가상 시나리오를 취할 수 있습니다 . 간단한 클래스와 같이 너무 많이 보일 수도 ConnectionPool있지만 기본적인 의도는 간단한 예제와 함께 낮은 커플 링 과 높은 응집력 을 나타내는 것이므로 도움이 될 것입니다.

1. 연결 지원
2. 연결을 해제하다
3. 연결 대 사용 횟수에 대한 통계 얻기
4. 연결 대 시간에 대한 통계 얻기
5. 나중에 검색 할 수 있도록 연결 검색 및 릴리스 정보를 데이터베이스에 저장하십시오.

응집력 이 낮 으면ConnectionPool 이 모든 기능 / 책임을 아래처럼 단일 클래스에 강제로 채워 클래스를 설계 할 수 있습니다. 이 단일 클래스는 연결 관리, 데이터베이스와의 상호 작용 및 연결 통계 유지 관리를 담당합니다.

로 높은 응집력 우리는 클래스에서 이러한 책임을 할당하고 더 유지 보수 및 재사용 할 수 있습니다.

낮은 커플 링 을 설명하기 위해 ConnectionPool위 의 높은 응집력 다이어그램을 계속합니다 . 위의 다이어그램을 보면 높은 응집력을 지원하지만 클래스와 ConnectionPool밀접하게 연결 되어 있으며 직접 상호 작용합니다. 대신 커플 링을 줄이기 위해 인터페이스를 도입 하고이 두 클래스가 인터페이스를 구현하고 클래스에 등록하도록 할 수 있습니다 . 그리고는 이 청취자를 반복 및 연결 GET 및 출시 이벤트를 통보하고 덜 커플 링을 허용합니다.ConnectionStatisticsPersistentStoreConnectionListenerConnectionPoolConnectionPool

참고 / 단어 또는주의 : 이 간단한 시나리오에서는 과도하게 보일 수 있지만 응용 프로그램이 여러 타사 서비스와 상호 작용하여 트랜잭션을 완료해야하는 실시간 시나리오를 상상하는 경우 : 코드를 타사 서비스와 직접 연결 이는 타사 서비스의 변경으로 인해 여러 위치에서 코드가 변경 될 수 있음을 의미합니다. 대신 Facade이러한 여러 서비스와 내부적으로 상호 작용하고 서비스의 모든 변경이 로컬에 Facade적용 되고 타사와의 낮은 연결을 강제 할 수 있습니다. 서비스.

---

응집력이 증가하고 커플 링이 감소하면 소프트웨어 디자인이 향상됩니다.

Cohesion은 기능을 분할하여 기능과 관련이있는 데이터와 간결하고 밀접한 관계를 유지하며, 분리는 기능 구현이 시스템의 나머지 부분과 분리되도록합니다.

디커플링을 사용하면 소프트웨어의 다른 부분에 영향을주지 않고 구현을 변경할 수 있습니다.

응집력 은 구현이 기능에 더 구체적이고 유지 관리가 더 쉬워 지도록합니다.

결합을 줄이고 응집력을 높이는 가장 효과적인 방법은 인터페이스에 의한 설계 입니다.

그것은 주요 기능 객체가 구현하는 인터페이스를 통해서만 서로 '알아야'한다는 것입니다. 인터페이스의 구현은 자연스러운 결과로서 응집력을 도입합니다.

일부 시나리오에서는 현실적이지 않지만 작동하는 디자인 목표가되어야합니다.

예 (매우 스케치) :

public interface IStackoverFlowQuestion
      void SetAnswered(IUserProfile user);
      void VoteUp(IUserProfile user);
      void VoteDown(IUserProfile user);
}

public class NormalQuestion implements IStackoverflowQuestion {
      protected Integer vote_ = new Integer(0);
      protected IUserProfile user_ = null;
      protected IUserProfile answered_ = null;

      public void VoteUp(IUserProfile user) {
           vote_++;
           // code to ... add to user profile
      }

      public void VoteDown(IUserProfile user) {
          decrement and update profile
      }

      public SetAnswered(IUserProfile answer) {
           answered_ = answer
           // update u
      }
}

public class CommunityWikiQuestion implements IStackoverflowQuestion {
     public void VoteUp(IUserProfile user) { // do not update profile }
     public void VoteDown(IUserProfile user) { // do not update profile }
     public void SetAnswered(IUserProfile user) { // do not update profile }
}

코드베이스의 다른 곳에서는 질문에 관계없이 질문을 처리하는 모듈을 가질 수 있습니다.

public class OtherModuleProcessor {
    public void Process(List<IStackoverflowQuestion> questions) {
       ... process each question.
    }
}

---

응집력에 대한 최고의 설명은 Bob 아저씨의 Clean Code에서 나옵니다.

클래스에는 적은 수의 인스턴스 변수가 있어야합니다. 클래스의 각 메소드는 하나 이상의 해당 변수를 조작해야합니다. 일반적으로 메소드가 더 많은 변수를 조작할수록 해당 메소드가 클래스에 더 응집력이 있습니다. 각 방법에서 각 변수를 사용하는 클래스는 최대한 응집력이 있습니다.

일반적으로 이러한 최대 응집력있는 클래스를 만드는 것은 바람직하지 않습니다. 반면에 응집력을 높이고 싶습니다 . 응집력이 높으면 클래스의 메소드와 변수가 서로 의존적이며 논리적 전체로서 함께 매달려 있음을 의미합니다.

함수를 작게 유지하고 매개 변수 목록을 짧게 유지하는 전략은 때때로 메소드의 서브 세트에 의해 사용되는 인스턴스 변수의 확산으로 이어질 수 있습니다. 이런 일이 발생하면 거의 항상 다른 클래스가 더 큰 클래스에서 벗어나려고한다는 것을 의미합니다. 변수와 메소드를 둘 이상의 클래스로 분리하여 새 클래스가 더 응집력이 있도록해야합니다.

---

소프트웨어 엔지니어링의 응집력 은 특정 모듈의 요소가 함께 속하는 정도입니다. 따라서 소프트웨어 모듈의 소스 코드로 표현 된 각 기능이 얼마나 밀접하게 관련되어 있는지를 측정 한 것입니다.

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

예제와 그림으로 조금 더 자세히 읽고 싶다면 이것 에 대한 블로그 게시물을 작성했습니다 . 나는 그것이 당신의 대부분의 질문에 대답한다고 생각합니다.

---

간단히 말해서 Cohesion 은 코드 기반의 일부가 논리적으로 단일 원자 단위를 형성하는 정도를 나타냅니다. 반면 커플 링 은 단일 유닛이 다른 유닛과 독립된 정도를 나타냅니다. 즉, 둘 이상의 장치 간 연결 수입니다. 숫자가 적을수록 커플 링이 낮아집니다.

본질적으로 높은 응집력은 서로 관련된 코드 기반의 일부를 한 곳에 유지하는 것을 의미합니다. 낮은 결합은 동시에 코드베이스의 관련되지 않은 부분을 가능한 많이 분리하는 것입니다.

응집력 및 결합 관점의 코드 유형 :

지침을 따르는 코드가 이상적 입니다. 느슨하게 결합되고 응집력이 있습니다. 이 그림으로 그러한 코드를 설명 할 수 있습니다.

God Object 는 높은 응집력과 높은 결합력을 도입 한 결과입니다. 안티 패턴이며 기본적으로 모든 작업을 한 번에 수행하는 단일 코드 조각을 나타냅니다. 다른 클래스 또는 모듈 사이의 경계가 잘못 선택 되면 잘못 선택 됩니다.

파괴적인 디커플링 이 가장 흥미로운 것입니다. 프로그래머가 코드베이스를 너무 많이 분리하여 코드가 완전히 초점을 잃을 때 종종 발생합니다.

여기서 더 읽어 보세요

---

cohesion refers all about how a single class is designed. Cohesion is the Object Oriented principle most closely associated with making sure that a class is designed with a single, well-focused purpose. The more focused a class is, the cohesiveness of that class is more. The advantages of high cohesion is that such classes are much easier to maintain (and less frequently changed) than classes with low cohesion. Another benefit of high cohesion is that classes with a well-focused purpose tend to be more reusable than other classes.

In the above image, we can see that in low cohesion only one class is responsible to execute lots of job which are not in common which reduces the chance of re-usability and maintenance. But in high cohesion there is a separate class for all the jobs to execute a specific job, which result better usability and maintenance.

---

Cohesion (Co-hesion) : Co which means together, hesion which means to stick. The System of sticking together of particles of different substances.

For real-life example:

img Courtesy

Whole is Greater than the Sum of the Parts -Aristotle.

• Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”. Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand. wiki

• Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability. wiki

---

I think the differences can be put as the following:

• Cohesion represents the degree to which a part of a code base forms a logically single, atomic unit.
• Coupling represents the degree to which a single unit is independent from others.
• It’s impossible to archive full decoupling without damaging cohesion, and vice versa.

In this blog post I write about it in more detail.

---

Cohesion is an indication of the relative functional strength of a module.

• A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.

• Conventional view:

  the “single-mindedness” of a module

• OO view:

  cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself

• Levels of cohesion

  Functional

  Layer

  Communicational

  Sequential

  Procedural

  Temporal

  utility

Coupling is an indication of the relative interdependence among modules.

• Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

• Conventional View : The degree to which a component is connected to other components and to the external world

• OO view: a qualitative measure of the degree to which classes are connected to one another

• Level of coupling

  Content

  Common

  Control

  Stamp

  Data

  Routine call

  Type use

  Inclusion or import

  External #

---

Coupling = interaction / relationship between two modules... Cohesion = interaction between two elements within a module.

A software is consisting of many modules. Module consists of elements. Consider a module is a program. A function within a program is a element.

At run time, output of a program is used as input for another program. This is called module to module interaction or process to process communication. This is also called as Coupling.

Within a single program, output of a function is passed to another function. This is called interaction of elements within a module. This is also called as Cohesion.

Example:

Coupling = communication in between 2 different families... Cohesion = communication in between father-mother-child within a family.

---

Simply put, cohesion means that a class should represent a single concept.

The public interface of a class is cohesive if all the class features are related to the concept that the class represents. For example, instead of having CashRegister class, having CashRegister and Coin features cohesion makes it into 2 classes - CashRegister and Coin class.

In coupling, one class depends on another as it uses the objects of the class.

The problem with high coupling is that it can create side effects. One change in one class could cause an unexpected error in the other class and could break the whole code.

Generally, high cohesion and low coupling is considered high quality OOP.

---

The term cohesion is indeed a little counter intuitive for what it means in software design.

Cohesion common meaning is that something that sticks together well, is united, which are characterized by strong bond like molecular attraction. However in software design, it means striving for a class that ideally does only one thing, so multiple sub-modules are not even involved.

아마도 우리는 이런 식으로 생각할 수 있습니다. 부품이 유일한 부품 일 때 가장 응집력이 높습니다 (한 가지만 수행하고 더 이상 분해 할 수 없음). 이것이 소프트웨어 디자인에서 원하는 것입니다. 응집력은 단순히 "단일 책임"또는 "문제 분리"의 또 다른 이름입니다.

반면에 커플 링 이라는 용어 는 매우 직관적이므로 모듈이 너무 많은 다른 모듈에 의존하지 않고 연결된 모듈을 liskov 대체 원칙에 따라 쉽게 대체 할 수 있음을 의미합니다 .

참고 URL : https://stackoverflow.com/questions/3085285/difference-between-cohesion-and-coupling