🔗 높은 응집도와 낮은 결합도의 비밀, 소프트웨어 설계의 황금률! 🤝

왜 갑자기 "응집도와 결합도"일까?

오늘은 코드 리뷰를 하다가 팀원과 설계에 대해 이야기를 나누던 중, "응집도(Cohesion)"와 "결합도(Coupling)"라는 용어가 나왔습니다. 사실 소프트웨어 설계에서 자주 언급되지만, 그 의미를 정확히 알고 있는 사람은 의외로 적습니다. 그래서 이번 기회에 저도 다시 한번 정리하고, 이 개념을 보다 쉽게 설명하려 합니다.

설계의 핵심은 "변경에 유연하고 유지보수가 쉬운 코드"입니다. 이를 실현하기 위해 꼭 알아야 할 것이 바로 응집도와 결합도입니다. 자, 이제 차근차근 알아봅시다!

---

🧩 응집도(Cohesion): 모듈의 단단함

응집도는 모듈 내 구성 요소들이 얼마나 밀접하게 관련되어 있는지를 측정하는 척도입니다. 높은 응집도는 모듈이 단일 책임 원칙(Single Responsibility Principle, SRP)을 잘 따르고 있다는 것을 의미합니다. 응집도가 높을수록 모듈은 명확한 목적을 가지고 있으며, 변경 시 다른 모듈에 미치는 영향이 줄어듭니다.

높은 응집도의 예시

// 높은 응집도를 가진 UserAuthentication 모듈
public class UserAuthentication {
    public boolean login(String username, String password) {
        // 로그인 로직
        return true;
    }

    public void logout() {
        // 로그아웃 로직
    }

    public boolean register(String username, String password) {
        // 회원가입 로직
        return true;
    }
}

• 이 모듈은 인증과 관련된 기능만 처리합니다.

낮은 응집도의 예시

// 낮은 응집도를 가진 클래스
public class UserModule {
    public boolean login(String username, String password) {
        // 로그인 로직
        return true;
    }

    public void connectToDatabase() {
        // 데이터베이스 연결 로직 (불필요한 책임)
    }

    public void renderUI() {
        // 사용자 인터페이스 렌더링 (불필요한 책임)
    }
}

• 인증 모듈에 데이터베이스 연결과 UI 렌더링 같은 불필요한 책임이 포함되어 있습니다.

---

🔗 결합도(Coupling): 모듈 간 유연함

결합도는 한 모듈이 다른 모듈에 얼마나 의존적인지를 나타냅니다. 결합도가 낮을수록 모듈 간 독립성이 높아지고, 변경에 따른 영향 범위가 줄어듭니다.

낮은 결합도의 예시

// 인터페이스를 활용한 낮은 결합도 설계
public interface PaymentProcessor {
    void processPayment(double amount);
}

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        // 신용카드 결제 처리 로직
    }
}

public class OrderService {
    private PaymentProcessor paymentProcessor;

    public OrderService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }

    public void placeOrder(double amount) {
        paymentProcessor.processPayment(amount);
    }
}

• OrderService는 PaymentProcessor 인터페이스에 의존하며, 구체적인 구현체에는 의존하지 않습니다.

높은 결합도의 예시

// 특정 클래스에 직접 의존하는 높은 결합도 설계
public class OrderService {
    private CreditCardProcessor creditCardProcessor = new CreditCardProcessor();

    public void placeOrder(double amount) {
        creditCardProcessor.processPayment(amount);
    }
}

• OrderService가 CreditCardProcessor 클래스에 직접 의존하기 때문에, 다른 결제 프로세서를 도입하려면 수정 범위가 커집니다.

---

🛡️ 캡슐화와의 관계

캡슐화는 객체의 내부 상태를 숨기고, 필요한 인터페이스만 노출하여 내부 구현 변경의 영향을 최소화하는 원칙입니다. 캡슐화를 잘 적용하면 응집도를 높이고 결합도를 낮출 수 있습니다.

캡슐화의 예시

public class BankAccount {
    private double balance;

    public BankAccount(double initialBalance) {
        this.balance = initialBalance;
    }

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {
        if (amount > 0) {
            balance += amount;
        }
    }

    public void withdraw(double amount) {
        if (amount > 0 && amount <= balance) {
            balance -= amount;
        }
    }
}

• balance 필드는 private으로 선언되어 외부에서 직접 접근할 수 없습니다. 내부 구현을 보호하면서도 필요한 기능은 제공합니다.

---

📏 좋은 설계의 지표

1. 높은 응집도: 각 모듈이 단일 책임 원칙을 잘 따름.
2. 낮은 결합도: 모듈 간 상호작용을 최소화.

이 두 가지를 실천하면, 변경에 유연하고 유지보수가 쉬운 코드를 작성할 수 있습니다.

비유:

높은 응집도와 낮은 결합도의 설계는 독립적으로 각자의 역할을 잘 수행하면서 필요한 순간 협력하는 드림팀과 같습니다.

---

📚 추가 학습 자료

• 우아한테크세미나: 우아한객체지향 by 조영호
• 10분 테코톡: 아루의 객체지향과 추상화 수준
• 10분 테코톡: 웨지의 OOP

---