TIL

Chapter 31 결합도와 결합도 제거

• ‘현금흐름할인’은 일부 결합도를 설명한다.
  • 결합도가 생겨도 빠르게 코드를 작성하는 길을 선택
  • 반면 결합 없이 더 긴 시간과 노력을 들여 코드를 작성할 수도 있다.

• 구현할 당시에는 결합도가 있어도 구현하는 것이 경제적이었겠지만 (수익은 먼저, 비용은 나중에) 이제 그 ‘나중’을 생각할 때다.

• 시스템에 결합도가 존재하는 이유
  • 일단 구현하는 것이 당장은 경제적이어서
  • 방금 전까지만 해도 결합이 문제가 되지 않아서
  • 결합도는 피할 수 없어서

• 결합도가 왜 있는지는 중요하지 않고 언제 결합도 비용을 지불할 것인가가 중요하다.

• 통신 프로토콜 예제를 살펴보자.
  • Sender와 Receiver에겐 결합이 존재한다.
  • Sender가 보내는 필드가 변경되면 Receiver쪽에 해당 필드에 해당하는 메서드를 추가하거나 변경해야 한다.

interface Sender {
  fun writeField1()
  fun writeField2()
}

interface Receiver {
  fun readField1()
  fun readField2()
}

• 아래처럼 메서드를 변경하면 결합이 사라진다.
  • 세 번째 필드를 추가해도 코드를 변경할 필요는 없다.
  • 하지만 여전히 Sender 내부 깊은 곳에선 세 번째 필드를 계산해야 하며 receive 함수는 send 함수가 세 번째 필드를 추가하지 않으면 읽을 수 없다.

interface Sender {
  fun writeField(format: Format) // map 형태의 파라미터를 정의
}

interface Receiver {
  fun readField(format: Format)
}

• 한 종류 코드 변경에 대한 결합도를 줄일수록 다른 종류의 코드 변경에 대한 결합도가 커진다.
  • 즉 모든 결합을 다 색출하듯 없애려고 애쓰지 말아야 한다는 것이다.
  • 그렇게 만들어진 결합도는 그만한 가치가 없다.
• 소프트웨어 설계가 어려운 것은 당옇나다.
  • 결합도 비용을 지불할 수도, 결합도 제거 비용을 지불하고 이점을 얻을 수도 있다.
  • 절충점을 찾아야 한다.