객체 간의 결합도(Coupling)와 응집도(Cohesion)의 관계

결합도와 응집도는 소프트웨어 구조 품질을 설명하는 가장 기본적인 두 축이다.

결합도 → 모듈 간 의존의 강도를 의미

응집도 → 하나의 모듈 내부에서 책임이 얼마나 잘 모여 있는지를 나타냄

모듈

• 소프트웨어를 각 기능별로 나누어진 소스 단위
• 모듈은 문맥에 따라 함수, 클래스, 패키지, Gradle 모듈처럼 서로 다른 크기의 소프트웨어 구성 단위를 의미할 수 있다. 결합도와 응집도는 이러한 여러 수준에서 모두 판단할 수 있다.

모듈화

문제가 복잡하고 큰 문제라면, 이 문제를 작은 부분으로 쪼개나가는 것

모듈의 효율성

결합도가 낮고 응집도가 높을 수록 모듈화의 효율성이 높다

객체지향 언어인지 절차지향 언어인지와 관계없이, 모듈 내부의 관련 기능은 함께 모으고 모듈 사이의 불필요한 의존은 줄이는 것이 좋은 설계의 기본 방향이다.

이 말을 다시 정리해보자면, 좋은 모듈화는 목적에 맞는 기능만으로 모듈을 나누게 되는데, 각각의 모듈은 주어진 기능만을 독립적으로 수행하기 때문에 재사용성이 높고 코드의 이해/수정이 용이하기 때문이다

---

결합도(Coupling)

• 모듈(클래스 파일)간의 상호 의존 정도 또는 연관된 관계의 끈끈함 정도를 의미
• 결합도를 의존도라고 부른다.

결합도가 높다는 것은 모듈들이 밀접하게 연결되어 있어 한 모듈의 변경 사항이 다른 모듈에 영향을 미칠 수 있다. 반대로 결합도 낮다는 것은 모듈들이 독립적이어서 한 모듈의 변경 사항이 다른 모듈에 미치는 영향이 미미하다.

결합도가 높다는 것을 예를 들어보면, 여행 플랫폼에서 회원 예매를 구축한다고 할 때 예매 로직에서 회원 가입 로직을 알고 있을 때 결합도가 높다고 할 수 있다. 예매 로직에서는 로그인한 회원의 정보만 알고 있으면 결합도를 낮출 수 있다.

기준

즉, 어떤 클래스가 다른 클래스에 대해 너무 자세히 알고 있다면 두 모듈은 높은 결합도를 가지게 되고, 반대로 어떤 클래스가 다른 클래스에 대해 꼭 필요한 지식만 가지고 있다면 두 모듈은 낮은 결합도를 가진다고 말할 수 있는 것

• 인터페이스를 사용하여 협력에 필요한 최소한의 계약에만 의존해야 한다.
  • 이 경우에 인터페이스를 사용했더라도 호출자가 내부 영속성 구조인 UserJpaEntity 까지 알고 있다면 여전히 결합도가 높다

 

interface UserService {
    UserJpaEntity findUserEntityWithPasswordAndLoginHistory(Long userId);
}

 

• • 반면, 아래와 같이 필요한 정보만 노출하면 결합도가 낮아질 수 있다

  interface CurrentUserProvider {
      CurrentUser getCurrentUser();
  }

→낮은 결합도는 변경의 영향을 줄여주며, OCP를 지키기 쉬운 구조를 만드는 데 도움을 준다.

• 확장에는 열려있고 변경에는 닫혀있는 클래스
• 다형성을 잘 지킨 클래스

---

응집도(Cohesion)

모듈 내 요소들이 하나의 명확한 목적을 달성하기 위해 얼마나 긴밀하게 협력하는 지를 나타내는 정도이다.

한 모듈이 하나의 기능(책임)을 갖고 있다면 응집도가 높은 것

한 모듈이 여러 기능을 갖고 있는 것은 응집도가 낮은 것이다.

응집도가 높은 모듈은 하나의 모듈 안에 함수나 데이터와 같은 구성 요소들이 하나의 기능을 구현하기 위해 필요한 것들만 배치되어 있고 긴밀하게 협력한다. 반대로 응집도가 낮은 모듈은 모듈 내부에 서로 관련 없는 함수나 데이터들이 존재하거나 관련성이 적은 여러 기능들이 서로 다른 목적을 추구하며 산재해 있다.

예를 들어, 여행 프로젝트에서 예매 처리를 담당하는 클래스에서 로그 아웃을 하는 메서드가 있다면, 이것은 응집도가 낮은 것이다. 따라서 클래스를 분리하는 게 응집도를 높일 수 있다.

응집도를 판단할 때는 메서드들이 같은 데이터를 사용하는지만 보는 것이 아니라, 같은 이유로 함께 변경되는지도 살펴봐야 한다.

---

결합도와 응집도

서론 관련된 책임을 하나의 모듈 안에 모으면 응집도가 높아지고, 관련 없는 책임을 다른 모듈로 분리하면 모듈 사이의 불필요한 의존도 줄어든다.

하지만 높은 응집도를 만들기 위해 무조건 클래스를 작게 나누는 것이 아니라, 함께 변경되고 함께 동작하는 책임은 모으고 서로 다른 이유로 변경되는 책임은 분리해야 한다.

---

코드를 판단하는 질문

응집도를 판단하는 질문

• 이 클래스의 메서드들을 한 문장으로 설명할 수 있는가?
• 메서드들이 동일한 상태나 데이터를 중심으로 동작하는가?
• 클래스 이름과 관계없는 메서드가 들어 있지는 않은가?
• 메서드들이 비슷한 이유로 함께 변경되는가?
• 클래스 이름에 Manager, Util, Helper처럼 책임이 모호한 단어가 붙어 있지는 않은가?

결합도를 판단하는 질문

• 다른 객체의 내부 구현 방식을 알고 있는가?
• 다른 객체의 필드나 DB Entity를 직접 사용하고 있는가?
• 한 클래스를 변경했을 때 여러 클래스가 함께 변경되는가?
• 구체 클래스 대신 필요한 역할이나 계약에 의존하고 있는가?
• 메서드의 매개변수로 정말 필요한 정보만 전달하고 있는가?
• 다른 모듈의 상태를 직접 변경하고 있지는 않은가?

---

참고자료

https://wikidocs.net/369737

https://inpa.tistory.com/entry/OOP-💠-객체의-결합도-응집도-의미와-단계-이해하기-쉽게-정리

https://www.geeksforgeeks.org/software-engineering/software-engineering-coupling-and-cohesion/