[오브젝트] - 설계 품질과 트레이드오프

💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다.

 

객체지향 설계를 하는 이유는 궁극적으로 앞으로의 설계 변경에 쉽게 대응하기 위함인 것 같다.

책에서는 왜 객체지향설계를 하면 설계변경에 대응하기 쉬운지 데이터지향 설계를 했을 때의 단점을 보여주면서 설명해 주고 있다.

또한 좋은 설계를 판단하는 기준으로 캡슐화, 응집도, 결합도에 대해서 설명하고 있다.

캡슐화

• 목적
  • 객체의 내부 구현을 외부로 부터 감추는 것
  • 구현이란?
    • 변경 가능성이 높은 부분
  • 인터페이스?
    • 상대적으로 안정적인 부분
  • 불안정한(변경가능성 높은) 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화하자
• 궁극적으로 이뤄내려는 것
  • 높은 응집도와 낮은 결합도는 캡슐화로 부터 나온다

응집도

• 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도
  • 하나의 변경이 발생할때 모듈 전체가 바뀌면 응집도가 높은 것, 모듈 일부만 변경되면 응집도가 낮은 것
  • 하나의 변경이 발생할때 하나의 모듈만 변경되면 응집도가 높은 것, 여러 모듈이 같이 변경되면 응집도가 낮은 것
• 응집도가 높을 수록 변경 대상과 범위가 명확하기 때문에 변경하기 쉬움

결합도

• 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도
  • 하나의 모듈을 수정하기 위해 다른 모듈을 얼마나 많이 수정해야하는지 나타냄

데이터 중심 설계의 문제점

• 캡슐화 위반 사례
  • 과도한 접근자와 수정자를 통해 객체 내부의 데이터에 접근함
    • 접근자와 수정자를 과도 하게 생성하는 것 자체가 외부 객체에 현재 객체안에 어떤 데이터가 있는지 알려주는 꼴
  • 객체의 인터페이스에 구현이 노출되는 경우
    • 예시
      • 인터페이스의 매개 변수로 객체 내부 데이터를 받는 경우
    • 이또한 외부로 객체 안에 어떤 데이터가 있는지 알려주는 꼴
• 높은 결합도
  • 여러 객체들의 데이터를 사용하는 제어로직이 특정 객체에 집중될 가능성이 높아짐
  • 단점
    • 특정 객체의 데이터 타입이 바뀐다면 제어로직이 들어있는 객체또한 수정해 줘야되는 문제 발생
    • 거대한 의존성 덩어리가 되어버림

느낀점

객체 지향 설계가 무조건 좋냐? 에대해서 고민이 있었는데 그에 대한 생각을 좀 정리 할 수 있었던 것 같다.

변경이 자주 일어날 것 같은 모듈이라면 적용해보자라는 생각이 들었다. 책에서도 확장할 여지가 없는 모듈의 경우에는 꼭 적용해야되는 것은 아니다라고 이야기 하고 있었다.

최근 작성하는 코드들에서 객체의 인터페이스에 내부 구현을 노출 시키는 경우가 많았던 것 같다는 생각을 하였다. 아직 데이터 중심 설계에서 벗어나지 못했다는 생각을 하였다. 다음 장을 읽고 어떻게 고칠 수 있을지 알아보고 새로 구현하는 카메라 시스템에는 꼭 적용을 해봐야 겠다.