4장 설계 품질과 트레이드오프

[rilac1]

4장 설계 품질과 트레이드오프

캡슐화

• 객체지향에서 가장 중요한 원리는 캡슐화다.
• 변경 가능성이 높은 부분을 객체 내부로 숨기는 추상화 기법
• 변경될 가능성이 높은 부분을 구현이라 부르고, 상대적으로 안정적인 부분을 인터페이스라고 부른다.
  • 여기서 객체가 가진 데이터(객체의 상태)는 구현에 속한다.

응집도와 결합도

• 응집도
  • 모듈에 포함된 내부 요소들이 연관되어 있는 정도.
  • 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 갖는다.
  • 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도
• 결합도
  • 의존성의 정도.
  • 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지
  • 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도
• 높은 응집도와 낮은 결합도를 가진 모듈로 구성된 설계가 좋은 설계다.
  • 인터페이스에 대해 프로그래밍하라
  • 캡슐화를 지키면 응집도는 높아지고 결합도는 낮아진다. 따라서 먼저 캡슐화를 향상시키기 위해 노력해라.

데이터 중심 설계의 문제점

• 캡슐화 위반

  • 객체가 수행할 책임이 아니라 내부에 저장할 데이터에 초점을 맞추게 된다.
  • 설계하는 시점에 협력에 관해 고민하지 않으면 과도한 접근자와 수정자를 가지게 되는 경향이 있다.
  • 접근자와 수정자에 과도하게 의존하는 설계 방식을 추측에 의한 설계 전략이라고 부른다.

• 높은 결합도

  • 각각의 객체가 자율적이지 못하고 데이터만 제공하게 되면 전체 시스템이 거대한 의존성 덩어리가 된다.
  • 이러한 경우에는 어떤 변경이 발생한다면 시스템 전체가 요동칠 수 밖에 없다.

• 낮은 응집도

• 절차적 프로그래밍 방식

  • 이로 인해 접근자와 수정자를 과도하게 추가하게 되고 캡슐화가 무너진다.
  • 데이터에 초점이 맞춰져 있다면 데이터를 처리하는 작업을 객체 내부에 두더라도 데이터에 관한 지식이 인터페이스에 고스란히 들어나게 된다.

느낀점

저는 도메인간의 협력이 필요한 비즈니스 로직을 구현할 때 해당 도메인 내부에 로직을 작성하지 않고, 각 도메인 서비스에 의존성을 갖는 외부 모듈에 로직을 작성했었습니다. 이유는 도메인이 서비스 레이어에 의존성을 갖지 않게 하기 위해서입니다. 책을 읽으면서 이러한 방식의 설계가 낮은 응집도를 가진 설계라는 것을 느낄 수 있었습니다.

도메인이 서비스에 의존성을 갖지 않고 다른 모듈과 협력하기 위해서는 해당 도메인과 협력하는 모든 도메인을 자율적인 객체로 설계하면 됩니다.

이런식으로 설계한다면 과도한 getter 사용을 지양할 수 있고, 추측에 의한 설계가 아닌 진정한 책임 중심의 설계를 할 수 있겠다는 생각을 해보았습니다.