[오브젝트] 3장 - 역할, 책임, 협력
    2022-09-05 10:00
    object

    • 객체지향의 본질 : 협력하는 객체들의 공동체를 창조하는 것

      • 기능 구현을 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할, 책임이 필요한지 파악

    • 객체들은 메시지를 주고 받으며 협력한다

    • 협력

      • 어플리케이션 기능 구현을 위한 객체들의 상호작용
      • 다른 객체에 무엇인가를 요청하는 것

    • 책임

      • 협력에 참여하기 위해 객체가 수행하는 로직

    • 역할

      • 협력안에서 수행하는 책임이 모여 객체가 수행하는 역할을 구성

    협력 - 객체 설계를 위한 문맥 제공

    객체지향 시스템 - 자율적인 객체들의 공동체 객체는 고립된 존재가 아닌 협력하는 사회적 존재

    • 한 객체는 어떤 것이 필요할 때 다른 객체에게 전적으로 위임 하거나 서로 협력한다.
      • 객체는 메시지를 통해서 협력한다
      • 메시지를 수신한 객체는 메서드를 실행해 요청에 응답
        • 객체는 수신받은 메시지를 처리할 방법을 스스로 선택한다
          • 객체는 자율적인 존재
          • 객체 내부 구현 (상태, 행동)을 캡슐화 하여 자율성을 확보

    객체 설계시 상태와 행동을 결정하는 기준

    객체가 참여하고 있는 협력에 따라 객체의 상태 와 행동이 정해진다.

    메세지 처리 가능 여부로 협력이 결정 -> 협력이 객체의 행동을 결정 -> 행동이 객체의 상태를 결정

    객체의 상태는 그 객체의 행동에 필요한 정보가 무엇인지로 결정된다.

    책임

    • 책임
      • 협력에 참여하기 위해 객체가 수행하는 행동
      • 하는 것과 아는 것, 두 가지 범주
      • 하는 것
        • 객체 생성 및 계산 수행 등 스스로 하는것
        • 다른 객체의 행동을 시작하는 것
        • 다른 객체의 활동을 제어, 조절하는 것
      • 아는 것
        • 사적인 정보를 아는것
        • 관련된 객체를 아는것
        • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

    책임을 할당하기 위해서는 협력을 정의해야한다. 협력을 설계하기 위해서는 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 바라보는것에서 시작.

    • 시스템은 사용자에게 제공해야 하는 기능인 시스템 책임을 파악
    • 시스템 책임을 더 작은 책임으로 분할
    • 분할된 책임을 수행할 수 있는 적절한 객체 (역할)을 찾아 책임 할당
    • 해당 객체에 책임 할당하여 두 객체가 협력하도록 한다.

    객체가 책임을 수행하게 하는 방법 : 메시지를 전송하는 것 책임을 할당하는 것 = 메시지의 이름을 결정하는 것

    메시지가 객체를 결정

    • 객체에게 책임을 할당하는 데 필요한 메시지를 먼저 식별
    • 메시지를 처리할 객체를 선택
    1. 객체가 최소한의 인터페이스를 가질 수 있게 된다
    2. 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다
      • 인터페이스는 무엇을 하는지는 표현하지만 어떻게 수행하는지는 노출하면 안된다.

    행동이 상태를 결정

    협력에 필요한 객체의 행동을 결정하고 나서 상태를 결정 협력 관계 속에서 다른 객체에게 무엇을 제공하고 무엇을 얻어야 할지를 고민하라

    역할을 통해 유연하고 재사용 가능한 협력을 얻는다

    • 역할

      • 다른 것으로 교체할 수 있는 책임의 집합
      • 다양한 종류의 객체를 수용할 수 있는 일종의 슬롯
      • 구체적인 객체들의 타입을 캡슐화하는 추상화
      • 역할을 구현하는 방법
        • 추상 클래스
        • 인터페이스

    • 협력에 적합한 책임을 수행하는 대상이

      • 한 종류라면 - 객체
      • 여러 종류의 객체들이 참여할 수 있다면 - 역할

    역할 덕분에 설계의 구성 요소를 추상화 할 수 있다

    느낀점

    이번장을 읽으면서, 머리로는 이해한 객체 설계 기법을 어떻게 하면 프로젝트에 적용해 볼 수 있을까 하는 고민을 해보았습니다.

    개인적으로 TDD가 모듈간의 의존도를 낮추고 객체지향적으로 프로그램을 설계하는데 도움을 줄 수 있지 않을까 생각해보았습니다.

    TDD를 기반으로 한다면 의존관계가 높은 테스트 코드 자체를 만들기가 어렵기 때문에 하나의 큰 기능을 작은 단위의 기능으로 쪼게게 됩니다.

    또한 자연스럽게 테스트를 통과하기 위한 메서드를 만든 다음, 메서드를 위한 필드값을 정의하는 순서로 구현이 이루어지기 때문에 행동이 상태를 결정하는 구조로 설계가 이루어 집니다.

    이러한 이유에서 TDD는 테스트 기법이 아닌 설계 기법이라 하지 않을까 생각해보게 되었습니다.