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

• 객체지향 설계의 핵심은 협력, 책임, 역할이다.
• 협력은 애플리케이션의 기능을 구현하게 위해 메시지를 주고받는 객체들 사이의 상호작용
• 책임은 객체가 다른 객체와 협력하기 위해 수행하는 행동
• 역할은 대체 가능한 책임의 집합이다.

1. 데이터 중심의 영화 예매 시스템

• 객체지향 설계에서는 두가지 방법을 이용해 시스템을 객체로ㅓ 분할할수 있다.
  1. 첫번째 방법은 상태를 분할의 중심축으로 삼는 방법이고
  2. 두번째 방법은 책임을 분할의 중심축으로 삼는 방법이다.
• 데이터 중심 관점
  1. 객체는 자신이 포함하고 있는 데이터를 조작하는데 필요한 오퍼레이션을 정의한다.
  2. 객체의 상태에 초점
  3. 객체를 독립된 데이터 덩어리로 봄
• 책임 중심 관점
  1. 객체는 다른 객체가 요청할 수 있는 오퍼레이션을 위해 필요한 상태를 보관한다.
  2. 객체의 행동에 초점
  3. 객체를 협력하는 공동체의 일원으로 봄
• 훌륭한 객체지향 설계는 책임 에 중심을 둬야 한다.
• 왜 why ?
  • 객체의 상태는 구현에 속한다. 구현은 언제든지 변경된다.
  • 상태를 객체분할의 중심축으로 삼으면 구현에 대한 세부사항이 객체의 인터페이스에 스며들게되서 캡슐화가 깨진다.
  • 상태변경은 인터페이스의 변경을 초래하며 인터페이스에 의존하는 모든 객체에게 변경의 영향이 끼친다.
• 하지만 객체를 중심에 두면 ?
  • 인터페이스로 캡슐화해서 구현변경에 대한 파장이 외부로 퍼지는것을 막는다.

데이터를 준비하자.

• https://github.com/abcdsds/object/tree/master/chapter04
• fork한 레포지토리

2. 설계 트레이드 오프

• 데이터 중심설계와 책임 중심설계의 장단점을 비교하기 위해 캡슐화, 응집도, 결합도 를 사용

캡슐화

• 상태와 행동을 하나의 객체안에 감추는것은 외부로부터 내부구현을 감추기 위한것.
  • 여기서 구현은 나중에 변경될 로직
  • 내부효과를 감추면 파급력을 외부로 전파하지 않아도 된다.
  • 외부로 노출시키는것은 상대적으로 안정적인 부분 ( 변경이 잦지 않은 것 ) 만 노출
  • 변경될 가능성이 높은 부분을 구현이라고 부른다
  • 상대적으로 안정적인 부분을 인터페이스라고 부른다.
  • 객체를 설계하기위한 가장 기본적인 아이디어는 변경의 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스에만 의존하도록 관계를 조절하는 것이다.
• 객체지향에서 가장 중요한 원리는 캡슐화 다.
• 캡슐화는 외부에서 알 필요가 없는 부분을 감춤으로써 대상을 단순화하는 추상화의 한 종류다.
• 객체지향설계에서 가장 중요한원리는 안정적인 인터페이스를 외부로 내세우고 세부구현은 인터페이스 뒤로 캡슐화 하는것.
• 정리하면 캡슐화는 변경 가능성이 높은것을 객체 내부로 숨기는 추상화 기법.
• 어떤것을 캡슐화 해야 하는가 ? 변경될 가능성이 있는 모든 것.

응집도와 결합도

응집도

• 응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다.
• 모듈내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 그 모듈은 높은 응집도를 가진다.
• 만약 모듈들이 각각 다른목적을 추구한다면 낮은 응집도를 가진다.
• 응집도는 객체지향에서는 얼마나 관련높은 책임들을 할당했는지를 나타낸다.

---

결합도

• 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도다.
• 어떤 모듈이 다른 모듈에 너무 자세한 부분까지 알고 있다면 두 모듈은 높은 결합도를 가진다.
• 어떤 모듈이 다른 모듈에대해 꼭 필요한 지식만 알고있다면 두 모듈은 낮은 결합도를 가진다.
• 객체지향의 관점에서는 얼마나 협력에 필요한 적절한 수준의 관계만을 유지하고 있는지를 나타낸다.

---

의문점

• 응집도는 어느정도가 높은것이고 낮은것인가
• 결합도는 어느정도가 높은것이고 낮은것인가

---

• 높은 응집도와 낮은 결합도를 가진 설계는 설계가 변경하기 쉽다.
• 변경의 관점에서 응집도란 변경이 발생할때 모듈 내부에서 발생하는 변경의 정도
• 하나의 변경을 위해 모듈전체가 같이 변경되면 ?
  • 높은 응집도
• 하나의 변경에 일부모듈만 변경되면 ?
  • 낮은 응집도
• 하나의 변경에 대해 하나의 모듈만 변경된다면 응집도는 높지만 다소의 모듈이 함께 변경해야 한다면 응집도가 낮은것이다.
• 결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도
• 다시 말해 하나의 모듈을 수정할때 얼마나 많은 모듈을 함께 수정해야 하는지를 나타낸다.
• 결합도가 높으면 높을수록 변경해야되는 모듈의 수가 늘어나기 때문에 변경하기가 어려워진다.
• 내부 구현을 변경했을때 다른 모듈도 변경해야 하는것은 높은 결합도
• 퍼블릭 인터페이스만을 수정했을때 모듈들을 변경해야 하는것은 낮은 결합도
• 결합도가 높아도 상관없는 경우
  • 변경될일이 거의없는 안정적인 모듈에 의존하는것은 문제가 되지 않는다.
  • 표준 라이브러리나 성숙 단게에 접어든 프레임워크
  • 예를 들어 자바의 String, ArrayList를 들수 있다.

3. 데이터 중심의 영화예매 시스템의 문제점

• 데이터 중심의 영화예매 시스템처럼 객체 내부의 접근자와 수정자에 과도하게 의존하는 설계방식을 추측에 의한 설계 전략 이라고 부른다
• 위와 같은 전략을 사용하면 캡슐화를 위반하고 변경에 취약한 설계를 얻게된다.

높은 결합도

• 데이터 중심 설계는 객채 내부의 구현이 외부 나타나고 내부 구현 변경시 외부에도 그 여파가 퍼져나간다는것이다.

낮은 응집도

• 서로 다른 이유로 변경되는 코드가 하나의 모듈 안에 공존할 때 모듈의 응집도가 낮다고 말한다.
• 낮은 응집도는 여러 모듈을 뭉쳐놓았기 때문에 변경과 아무 상관없는 코드들이 영향을 받게된다.
  • A와 B는 아무 관련이 없는데 A가 수정되서 문제가 발생하면 B도 안돌아가기 때문
• 그렇기 떄문에 하나의 요구사항을 변경하기 위해 동시에 여러 모듈을 수정해야한다.
• 응집도가 낮을경우 다른 모듈에 위치해야할 책임이 엉뚱하게 위치해있기 때문이다.

4. 자율적인 객체를 향해

캡슐화를 지켜라

• 캡슐화는 설계의 제1원리다.
• 데이터중심의 예매가 몸살을 앓는건 캡슐화를 위반했기 때문이다.
• 객체는 스스로의 상태를 책임져야하며 외부에서는 인터페이스에 정의된 메서드를 통해서만 상태에 접근할 수 있어야 한다.
• 접근권한자를 private으로 설정했다고 하더라도 게터세터를 쓰면 public으로 열어논것과 다름없다.

스스로 자신의 데이터를 책임지는 객체

• 상태와 행동을 객체라는 하나의 단위로 묶는 이유는 객체 스스로 자신의 상태를 처리할 수 있게하기 위해서다.
• 객체는 단순히 데이터 제공자가 아닌 객체 내부에 저장되는 데이터보다 객체가 협력에 참여하면서 수행할 책임을 정의하는 오퍼레이션이 더 중요하다.
• 데이터 중심 설계에서 객체를 구성하는 질문 두가지 ( 이렇게 하면 안된다 )
  1. 이 객체가 어떤 데이터를 포함해야 하는가 ?
  2. 이 객체가 데이터에 대해 수행해야하는 오퍼레이션은 무엇인가 ?

5. 하지만 여전히 부족하다.

• 설계가 조금 나아졌긴 했지만 여전히 첫번째 설계에서 발생했던 대부분의 문제는 두번째 설계에서도 여전히 발생한다.

캡슐화 위반

• 수정된 객체는 분명 자신의 데이터를 스스로 처리한다.
• 내부 구현의 변경이 외부로 퍼져나가는 파급효과 는 캡슐화가 부족하다는 명백한 증거다.
• 캡슐화의 진정한 의미는
  • 단순히 객체 내부의 데이터를 외부로 감추는 것 이상으로 단순히 내부속성을 외부로 감추는것은 데이터 캡슐화일 뿐이다.
  • 캡슐화란 변할수 있는 어떤것이라도 감추는것이다 그게 무엇이든 구현과 관련된것이라면.
  • 그것이 속성의 타입이건 할인정책의 종류건 상관없이 내부구현의 변경으로 인해 외부의 객체가 영향을 받는다면 캡슐화를 위반한것이다.
  • 설계에서 변하는것이 무엇인지 고려하고 변하는 개념을 캡슐화 해야 한다.

높은 결합도

• 캡슐화 위반으로 B객체 에 대한 내부 구현이 외부로 노출됬기 때문에 객체와 B객체의 결합도는 높을수 밖에 없다.
• 결합도가 높으면 변경에 영향을 많이 받는다.
• 캡슐화가 위반되서 그렇다 캡슐화가 제 1 원칙이다.

낮은 응집도

• 마찬가지로 캡슐화를 위반했기 때문이다.

6. 데이터 중심 설계의 문제점

• 3,4,5를 거쳐 변경해도 설계가 변경에 유연하지 못한 이유는 캡슐화를 위반해서다.
• 데이터 중심 설계의 문제점 두가지
  1. 데이터 중심의 설계는 본질적으로 너무 이른시기에 데이터에 관해 결정하도록 강요한다.
  2. 데이터중심의 설계에서는 협력이라는 문맥을 고려하지않고 객체를 고립시킨채 오퍼레이션을 결정한다.

데이터 중심 설계는 객체의 행동보다 상태에 초점을 맞춘다.

• 데이터 중심 설계에서 객체를 구성하는 질문 두가지 (4단락 마지막) 을 보면
• 데이터가 무엇인가부터 시작한다 이것은 처음부터 데이터를 너무 이른시기부터 초점을 맞추게 한다.
• 그렇게되면 객체는 단순 데이터 집합이고 캡슐화가 무너지게 된다.

데이터 중심 설계는 객체를 고립시킨 채 오퍼레이션을 정의하도록 만든다.

• 객체지향 애플리케이션을 구현한다는 것은 협력하는 객체들의 공동체를 구축한다는 것을 의미한다.
• 따라서 협력이라는 문맥 안에서 필요한 책임을 결정하고 이를 수행할 적절한 객체를 결정하는 것이 가장 중요하다.
• 캡슐화를 위반해서 인터페이스에 구현이 노출되어 있었기 때문에 다른 결합된 객체들도 영향을 받는다.