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

지난 내용 정리

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

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

• 책임이 무엇인가 VS 데이터가 무엇인가?

데이터 중심 관점

• 데이터 조작을 위한 오퍼레이션 정의
• 객체의 상태에 초점을 맞춰 구현
• 객체는 독립된 데이터 덩어리

책임 중심 관점

• 다른 객체가 요청할 수있는 오퍼레이션을 위해 필요한 상태 보관
• 객체의 행동에 초점
• 객체는 협력하는 공동체의 일원

채택

• 둘중 책임을 택한다. 그 이유는 '변경'이다.

데이터 중심 설계

• 객체 내부에 저장되어있는 데이터를 기반으로 시스템을 분할하는 방법이다.
  • 이 경우 멤버 변수간 배타적 사용 형태와 분기 처리 방식으로 진행된다

2. 설계 트레이드 오프

캡슐화 (변화하는 어떤 것이든 감추기)

• 상태, 행동이 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로 부터 감추기 위함이다.
  • 여기서 구현이란 나중에 변경가능성 높은 어떤것을 의미한다
  • 즉 변경가능성이 높은것은 구현 / 낮은것은 인터페이스
• 결국 캡슐화란 변경 가능성 높은 부분은 객체 내부로 숨긴다
  • 그 이유는 불안정한 부분과 안정 부분을 분리해서 변경 영향을 통제한다
  • 이것이 곧 설계의 품질이다

응집도와 결합도 (변경과 관련됨)

응집도

• 변경과 변경원인을 중심으로응집도
• 모든 내부에 요소들이 연관(하나의 목적으로)되어 있는 정도
• 변경 관점 : 변경이 발생할 때 모듈 내부가 변경되는 정도 의미

결합도

• 의존성에 대한 정도로서, 다른 모듈에 얼마나 많은 지식을 가지고 있는지
• 변경 관점 : 한 모듈의 변경을 위해, 다른 모듈이 얼마나 변경되는 정도
• 변경 원인 : 내부 구현이 변경 될 때 다른 모듈에 영향이 미치는 경우

좋은설계?

• 오늘 기능을 수행하면서, 내일의 변경을 수용할 수있는 설계
• 하나의 변경이 있을 때
  • 모듈 전체가 변경되면 응집도가 높고 / 모듈 일부가 변경되면 응집도가 낮다
  • 하나의 모듈만 변경되면 결합도가 낮고 / 다수의 모듈이 변경되면 결합도가 높다

왜냐하면 변경 대상과 범위가 명확해지기 때문이다.

• 결국 응집도가 높고, 결합도가 낮으면
  • 클래스가 아니라 인터페이스에서 의존하는 코드 작성을 하게되면 낮은 결합도여서 다른 모듈에 영향을 덜 미친다.

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

• 문제점
  • 캡슐화 위반 / 높은 결합도 / 낮은 응집도

캡슐화 위반

• 설계시 협력을 고민하지 않으면 -> 문맥을 추측하게 되고 -> 접근자와 수정자가 많아지고 -> 내부 구현이 인터페이스로 노출된다

높은 결합도

• 'ReservationAgency' 는 모든 의존성이 모이든 결합도의 집결지이다.

낮은 응집도

• 서로 다른 이유로 변경되는 코드가 하나의 모듈안에 '공존'시 모듈의 응집도가 낮다

참고 : SRP

• 여기서 말하는 책임은 변경의 이유이다.
  • 역할 책임 협력의 책임과는 다른것이다.

4. 자율적인 객체를 향해

• 객체에게 의미있는 메서드는 객체가 책임지는 것을 수행하는 메서드 이다.
• 예제의 Rectangle 클래스는 코드 중복과 변경에 취약하다

5. 여전히 부족한 리팩터링

• 내부 구현이 외부로 퍼져가는 파급효과(Ripple effect) 가 존재한다
  • 캡슐화가 부족한 증거이다
  • (나의 경우 인텔리 J 에서 변수명 한번에 수정하면서 파급효과를 직접 체감을 못하고있었다)
• 이 경우 정책 조건을 알고있는데 추가 변경 제거 시 모두 영향을 받는다.

정리

• 높은 결합도 -> 다른 모듈에 영향을 주어서 -> 캡슐화 위반
• 낮은 응집도 -> 다른 모듈에 영향을 주어서 -> 캡슐화 위반

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

원인

1. 너무 이른 시기에 데이터를 결정한다
2. 협력을 문맥에서 고려하지않고, 객체가 고립된다

실패이유

1. 접근자와 수정자로 이용하는데 사실상 필드를 public으로 둔 것과 같다
2. 인터페이스에 데이터가 노출이 된다 => 변경에 취약해진다

• 결국 너무 이른 시기에 데이터에 대한 고민을 하면 문제시 된다.