Skip to content

Latest commit

 

History

History
43 lines (40 loc) · 5.49 KB

chapter3.md

File metadata and controls

43 lines (40 loc) · 5.49 KB

3장 - 역할, 책임, 협력

  • 스터디 중 삼색볼펜법으로 체크한 부분들을 팀원들과 공유한 내용입니다.
  • 스터디원들이 2명 이상 겹치는 부분은 강조표시(BOLD)가 되어 있습니다.
  • 문장은 페이지의 오름차순으로 정렬되어 있습니다.

🔴 빨강 (아주 중요하다고 생각한 내용!)

  • 협력은 객체가 필요한 이유와 객체가 수행하는 행동의 동기를 제공한다.
  • Craig Larman은 이러한 분류 체계에 따라 객체의 책임을 크게 하는 것(doing)과 아는 것(knowing)의 두 가지 범주로 나누어 세분화하고 있다.
  • 이처럼 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법을 책임 주도 설계(Responsibility-Driven Design, RDD)라고 부른다.(83p)
  • 역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다.(87p)
  • 요점은 동일한 책임을 수행하는 역할을 기반으로 두 개의 협력을 하나로 통합할 수 있다는 것이다.(89p)
  • 역할은 특정한 객체의 종류를 캡슐화하기 때문에 동일한 역할을 수행하고 계약을 준수하는 대체 가능한 객체들은 다형적이다.(96p)

🔵 파랑 (중요하다고 생각한 내용!)

  • 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다.
  • 객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다.
  • 외부의 객체는 오직 메시지만 전송할 수 있을 뿐이며 메시지를 어떻게 처리할지는 메시지를 수신한 객체가 직접 결정한다.
  • 자율적인 객체란 자신의 상태를 직접 관리하고 스스로의 결정에 따라 행동하는 객체다.
  • 결과적으로 객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화하는 것이다.
  • 객체의 상태는 그 객체가 행동을 수행하는 데 필요한 정보가 무엇인지로 결정된다.
  • 객체는 자신이 맡은 책임을 수행하는 데 필요한 정보를 알고 있을 책임이 있다. 또한 객체는 자신이 할 수 없는 작업을 도와줄 객체를 알고 있을 책임이 있다.
  • 객체에게 얼마나 적절한 책임을 할당하느냐가 설계의 전체적인 품질을 결정한다.
  • 객체지향 설계는 시스템의 책임을 완료하는 데 필요한 더 작은 책임을 찾아내고 이를 객체들에게 할당하는 반복적인 과정을 통해 모양을 갖춰간다.
  • 정보 전문가에게 책임을 할당하는 것만으로도 상태와 행동을 함께 가지는 자율적인 객체를 만들 가능성이 높아지기 때문이다.(83p)
  • 객체의 인터페이스는 무엇을 하는지는 표현해야 하지만 어떻게 수행하는지를 노출해서는 안 된다.(84p)
  • 객체에게 책임을 할당하는 데 필요한 메시지를 먼저 식별하고 메시지를 처리할 객체를 나중에 선택했다는 것이 중요하다.(84p)
  • 객체가 충분히 추상적이면서 미니멀리즘을 따르는 인터페이스를 가지게 하고 싶다면 메시지가 객체를 선택하게 하라.(85p)
  • 상태는 단지 객체가 행동을 정상적으로 수행하기 위해 필요한 재료일 뿐이다.(85p)
  • 이처럼 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.(86p)
  • 역할은 다른 것으로 교체할 수 있는 책임의 집합이다.(88p)
  • DiscountPolicy 역할을 수행할 수 있는 어떤 객체라도 이 협력에 참여할 수 있게 됐다.(89p)
  • 레베카 워프스브록의 말을 인용하자면 협력에 참여하는 후보가 여러 종류의 객체에 의해 수행될 필요가 있다면 그 후보는 역할이 되지만 단지 한 종류의 객체만이 협력에 참여할 필요가 있다면 후보는 객체가 된다.(90p)
  • 다양한 객체들이 협력에 참여한다는 것이 확실하다면 역할로 시작하라. 하지만 모든 것이 안개 속에 둘러싸여 있고 정확한 결정을 내리기 어려운 상황이라면 구체적인 객체로 시작하라.(92p)
  • 협력이라는 관점에서는 세부적인 사항을 무시하고 추상화에 집중하는 것이 유용하다.(93p)

🟢 초록 (흥미롭다고 생각한 내용!)

  • 협력이라는 문맥을 고려하지 않고 행동을 결정하는 것은 아무런 의미가 없다.
  • 객체가 책임을 수행하게 하는 유일한 방법은 메시지를 전송하는 것이므로 책임을 할당한다는 것은 메시지의 이름을 결정하는 것과 같다.
  • 협력이 책임을 이끌어내고 책임이 협력에 참여할 객체를 결정한다.(84p)
  • 객체지향 패러다임에 갓 입문한 사람들이 가장 쉽게 빠지는 실수는 객체의 행동이 아니라 상태에 초점을 맞추는 것이다.(85p)
  • 일반적으로 역할은 객체가 협력에 참여하는 잠시 동안에만 존재하는 일시적인 개념이다. 역할은 모양이나 구조에 의해 정의될 수 없으며 오직 시스템의 문맥 안에서 무엇을 하는지에 의해서만 정의될 수 있다. 역할은 객체의 페르소나다.(95p)
  • 협력은 연극과 동일하고 코드는 극본과 동일하다.(95p)
  • 객체는 여러 역할을 가질 수 있지만 특정한 협력 안에서는 일시적으로 오직 하나의 역할만이 보여진다는 점에 주의하라.(96p)