Objects 5장 책임 할당하기

안녕하세요. 이 포스팅은 조영호 저자의 오브젝트라는 책을 정리한 포스팅입니다. 예제를 통해 같이 포스팅하고 싶었으나 내용이 방대하고 진도가 너무 느려져서 개인적인 정리내용만을 공유하고 추후에 다시 읽을 때 예제와 함께 업로드 하도록 하겠습니다.

Keywords

• 캡슐화
• 응집도
• 결합성
• 객체의 자율성
• Principles
  • Information expert pattern
  • Creator pattern
  • Polymorphism pattern
  • Protected Variations pattern

Points

• 객체지향설계는 Trade-Off이다. 다양한 설계 중 우리는 응집도가 높고 결합도가 낮은 방식을 택하는 것이 바람직하다.
• 변경된다는 것은 어떻게 알 수 있을까? 여러가지 기준들
  • 하나 이상의 변경 이유를 갖는 것은 캡슐화가 잘 되지 않은 경우(응집성이 낮거나 결합도가 높다는 의미)
    • 이는 서로 관련없는 혹은 관련성이 적은 것들이 하나의 클래스에 같이 있다는 의미 따라서 낮은 응집도가 초래하는 문제를 해결하기 위해서는 변경의 이유에 따라 클래스를 분리하여야 한다.
  • 인스턴스 변수가 초기화되는 시점
    • 다 같이 초기화되는 것이 아니라 일부끼리 분리되어 초기화 되는 경우 분리되는 것들끼리 클래스로 빼야 하는 경우가 많다.
  • 메서드들이 인스턴스 변수를 사용하는 것
    • 모든 메서드가 모든 인스턴스 변수를 사용한다면 응집성이 높다고 볼 수 있다.
    • 하지만 특정 메서드는 특정 인스턴스 변수만 이용하거나 이용하지 않는다면 이는 변경의 기준이 될 수 있다.
• 클래스를 잘게 분리하게 되면 같은 역할을 하지만 분리되는 경우가 존재한다. 이런 경우 메세지를 누구와 소통해야하는 것일까 모두와 소통해야 하는것인가?
  • 추상화, 다형성(인터페이스 , 추상클래스, 상속) 등이 사용될 시점이 왔다. (물론 둘다를 가지고 있어도 된다 하지만 의존성이 높아지고 낮은 구현단계에서 의존이 발생한다
  • Polymorphism pattern
    • 같은 역할을 하는 기능들은 분기를 통해서도 해결할 수 있지만 이보단 다형성을 통해 해결하면 더 확장성 있는 프로그램 구조를 가질 수 있다.
    • 객체의 타입에 따라 변하는 로직이 있을 때 변하는 로직을 담당할 책임을 어떻게 할당할 것인가? 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당하라.
  • Protected Variations pattern
    • 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라.
    • 변경될 가능성이 높은가? 캡슐화하라 다형성을 통해서

Dependency Choice

결합성과 응집성은 상충될 수 있다. 즉 응집성을 높이기 위해 역할을 옮기는 경우 다른 객체와 강하게 결합되는 경우도 존재한다. 그러한 경우 본인의 판단에 맞게 하면 된다.

Example

• Movie - DiscountCondition
• Screening - DiscountCondition

Useful Patterns

Responsibility Driven Development

• Information expert pattern
• Low coupling pattern
• High cohesion pattern
• Creator pattern
  • assign responsibility on the object that is already coupled with what is created
  • Object that create Reservation object

Check list during development

Checks everytime Object's

• coupliong
• cohesion

Domain Model

• 도메인 모델은 우리의 직관을 반영한다는 점에서 중요하다. 하지만 너무 완벽한 도메인 모델을 통해 구현을 진행하려 하지마라. 도메인 모델은 단순히 시작을 위한 설계에 불과하며 이는 과정에서 구현을 통해 계속 개선된다.
• 도메인 모델은 시작점을 제공하는 것이며 우리 혹은 사용자의 직관이라는 점에서 구현에 도움을 준다. 도메인 모델의 직관과 구현은 어느정도 일치하여야 이해가능한 프로그램의 개발이 가능하다는 의미이다.
• 도메인 모델에서 변경가능한 부분과 변경되지 않는 부분에 대한 설계는 같이 해주면 개발에서 용이하다 물론 하지 않더라도 혹은 못하더라도 구현과정에서 발견하면 변경하면 된다.

책임주도설계가 어려울 때

• 객체지향적인 설계 그리고 협력이라는 관점에서 역할배분은 매우 어려운 일이다. 이 부분이 어려운 것은 지극히 당연하며 이러한 어려움이 심하다면
• 작동하는 코드를 생성하고 이를 리팩토링하는 방법 또한 좋은 설계의 방법이다.
• 리팩토링 하는 방법
  • 기능 단위로 메서드 분리
  • 각 메서드에서 사용하는 데이터가 있는 클래스로 역할 이동