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

오브젝트

조영호님의 책 오브젝트를 보며 정리한 내용입니다.

문제가 될 시 해당글 삭제하겠습니다.

---

객체지향의 설계의 핵심은 역할, 책임, 협력이고 그 품질을 결정하는 가장 중요한 요소는 책임이다!

 

객체의 결합도와 응집도를 합리적인 수준으로 유지할 수 있는 중요한 원칙은
객체의 상태가 아닌, 객체의 행동에 초점을 맞추는 것이다. 
-> 상태의 초점을 맞추게 되면, 객체의 내부구현을 인터페이스에 노출시키는 결과를 낳게되어
유지 보수에 어려움을 겪는다.

 

[캡슐화](객체지향에서 복잡성을 다루는 추상화의 방법!)

• 상태와 행동을 하나의 객체 안으로 모으는 형태로, 객체의 내부 구현을 외부에 숨기기 위함이다.
• 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개한다.
• 객체 내의 상태값은 객체 내부에서 처리해야 한다! 외부에서 객체 내의 상태값을 변경하면 안된다!
• 변경될 가능성이 높으면 구현, 상대적으로 안정적인 부분을 인터페이스라 부른다.
  -> 외부에서는 인터페이스만 의존하도록 구성한다.

[응집도와 결합도]

응집도

• 모듈에 포함된 내부 요소들이 연관돼 있는 정도
  -> 모듈 내의 요소들이 하나의 목적을 향해 긴밀하게 협력하면 높은 응집도
  -> 모듈 내의 요소들이 서로 다른 목적을 추구한다면 낮은 응집도
  -> 응집도가 높은 모듈이 객체지향적으로 우수한 설계
• 변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도!
  -> 응집도가 높을수록 변경의 대상과 범위가 명확해지기 때문에, 코드를 변경하기 쉬워진다.
  -> 응집도가 높은 모듈은 변경을 통해 수정되는 부분을 위해 코드 구석구석을 헤매고 다니거나
  여러 모듈을 동시에 수정할 필요가 없다.

결합도

• 의존성의 정도를 나타내며, 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도
  -> 어떤 모듈이 다른 모듈에 대해 너무 자세한 부분까지 알고있다면 두 모듈은 높은 결합도를 가진다.
• 변경의 관점에서 결합도는 한 모듈이 변경되기 위해서 다른 변경을 요구하는 정도
  -> 결합도가 높은 모듈은 하나의 모듈을 수정할 때 수많은 모듈을 수정해야 하는 참사가 일어난다...(과거 프로젝트의 해당...)
  -> 내부 구현을 변경했을 때, 다른 모듈에 영향이 끼치는 경우 결합도가 높다고 표현한다.
  -> 인터페이스를 수정했을 때만, 모듈에 영향을 끼칠 때 결합도가 낮다고 표현한다.

[자율적인 객체]

캡슐화를 지켜라

• 객체에 상태 가시성을 private 로 설정했다고 해서 캡슐화가 지켜진 것이 아니다.
• 접근자와 수정자를 통해 외부로 제공되고 있다면 캡슐화가 지켜진 것이 아니다!
  => 진정한 캡슐화란! 단순히 객체 내부의 데이터를 외부에 감추는 것에서 끝나는 것이 아닌!!  
  변경될 수 있는 어떤 것이라도 감추는 것이다!!!(객체 내부의 모든 정보!!!)

캡슐화를 지키지 않았을 때 단점

1. 코드 중복이 생겨난다.(악의 근원!!)
2. 변경에 취약하다.. 
   -> 이러한 단점을 해결하기 위해서, 책임을 전문가에게 이동시켜야 한다!
   -> 인터페이스의 파라미터를 통해서 내부 객체의 정보가 새어 나간다면, 그 또한 객체지향적인 설계가 아니다!
   -> 파라미터가 없는 인터페이스의 경우에도 인터페이스 이름으로 내부의 구조를 드러낼 수 있다...(bad practice)
   => 내부 구현의 변경이 외부로 퍼져나갈 수 있다!(파급효과)

[데이터 중심 설계의 문제점]

1. 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 한다.
   - 데이터는 구현의 일부이다...
   - 우리는 구현보다 인터페이스(행동) 에 초점을 맞추어 개발해야 한다.
2. 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.
   - 데이터 중심 설계에서 초점은 객체의 외부가 아닌 내부로 향한다.. 
   - 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민하기 때문에, 이미 구현된 객체의 인터페이스에 억지로 끼워 맞출 수 밖에 없다.
   => 데이터 중심 설계가 변경에 취약한 가장 큰 이유!!