Skip to content

Latest commit

 

History

History
128 lines (90 loc) · 5.67 KB

05_책임과_메시지.md

File metadata and controls

128 lines (90 loc) · 5.67 KB

Chapter 5 : 책임과 메시지



다형성

  • 메시지 : 메시지는 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
  • 메서드 : 메시지의 수신자 객체는 메시지를 처리할 방법으로 특정 메서드를 실행

  • 다형성

    • 서로 다른 객체들이 다형성을 만족시킨다는 것 = 객체들이 동일한 책임을 공유한다는 것을 의미

    • 서로 다른 타입의 객체들이 동일한 메시지에 대해 서로 다른 메서드를 이용해 처리하는 메커니즘
      => 송신자가 수신자의 종류를 모르더라도 메시지를 전송할 수 있기 때문에 수신자의 종류를 캡슐화함
      = 송신자와 수신자 간의 객체 타입에 대한 결합도를 낮춤


  • 송신자가 수신자에 대해 적은 정보만 알고 있더라도 상호 협력이 가능하다는 사실이 설계의 품질에 미치는 영향
    • 협력이 유연해짐
      • 송신자에 대한 파급효과 없이 유연하게 협력 변경 가능
      • 수신자가 메시지를 이해하기만 하면 됨
    • 협력이 수행되는 방식을 확장할 수 있음
      • 협력의 구조 자체는 변하지 않음(세부적인 수행 방식은 쉽게 수정)
      • 협력을 확장할 때는 간단하게 새로운 유형의 객체를 협력에 끼워 맞추면 됨
    • 협력이 수행되는 방식을 재사용할 수 있음

=> 객체지향 패러다임이 강력한 이유 : 다형성을 이용해 협력을 유연하고 재사용 가능하고 확장 가능한 협력구조를 만들 수 있기 때문


메시지를 따라라

  • 객체지향 설계의 중심에는 메시지가 위치
    • 메시지를 중심으로 협력을 설계해 메시지가 객체를 선택하게 해야 함

      • 협력관계 속에서 다른 객체에게 무엇을 제공해야하고 다른 객체로부터 무엇을 얻어야하는가 라는 관점에서 접근해야 훌륭한 책임 수확

        = 객체가 어떤 메시지를 전송할 수 있고, 어떤 메시지를 이해할 수 있는지에 대해 집중

      • 그걸 위한 메시지에 대해 고민해서 설계하기


책임-주도 설계

  • What/Who 사이클 : 책임-주도 설계의 핵심
    • What : 어떤행위 필요한지(= 어떤 메시지 필요한지) 결정 후
    • Who : 행위 수행할 객체 결정
  • 객체가 아니라 객체가 주고받는 메시지에 초점 맞추게됨
  • 이렇게 메시지를 먼저 결정함으로써 객체의 인터페이스 발견가능

  • Tell, Don’t Ask (묻지말고 시켜라)
    • 어떤 객체가 메시지를 수신할지 알 수 없음
      -> 송신자는 수신할 객체의 내부 상태를 볼 수 없음
      (메시지 중심 설계는 메시지 수신자의 캡슐화를 증진시키며, 송신자와 수신자가 느슨하게 결합됨)
      -> 송신자는 수신자가 자신이 전송한 메시지를 잘 처리할 것을 믿고 메시지 전송할 수 밖에 없음



객체 인터페이스

  • 내부 구조를 몰라도 대상을 조작할 수 있도록 함
  • 인터페이스만 변경되지 않으면 내부 구조를 바꿔도 동작에 문제 없음
    • 대상이 변경되어도 동일 인터페이스를 사용한다면 문제 없음

인터페이스와 구현의 분리

  • 외부에 공개되는 인터페이스 & 내부에 감춰지는 구현

    = 객체의 외부와 내부를 명확히 구분하자

  • 분리하는 것 왜 중요?

    • 변경에 대한 영향 최소화하기 위해
      • 객체내부(상태와 메서드 구현)를 수정하더라도 객체 외부에 영향 안 미침

=> 변경될만한 부분을 객체 내부에 숨겨둠(캡슐화)
객체지향은 외부와 내부를 명확하게 구분하는 객체들로 구성된 협력공동체


  • 전통적인 개발방법과 객체지향 구분짓는 차이
    • 과거 : 상태(데이터)와 행동(프로세서)를 엄격히 구분했음
    • 현재 : 객체라는 틀에 데이터와 프로세서를 함께 묶어둠 = 객체의 자율성 보장



마무리

  • 객체가 자율적일수록
    • 추상화됨
    • 응집도 높아짐
    • 결합도 낮아짐
    • 캡슐화 증진
    • 인터페이스와 구현이 명확하게 분리
    • 설계의 유연성과 재사용성 향상

=> 변경에 의해 수정되어야 하는 범위가 명확 + 좁아짐


  • 협력 관계에서 주고받는 메시지가
    객체의 책임을 결정하고
    그 책임을 자율적으로 만드는 것이
    어플리케이션의 품질을 결정



💡 생각해볼 점

  • 정리해보자면
    • 주고받는 메시지를 통해 객체의 책임을 결정해야 한다
    • 이 때, 객체는 추상화, 캡슐화를 통해 자율적으로 만들어야 변경의 전파가 적다
  • 책을 읽으며 추상화와 캡슐화, 다형성의 중요성을 한번 더 짚고갈 수 있어 좋다
  • 객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때 뿐이다라는 문구를 통해 인터페이스 변경은 신중해야겠다는 생각이 들었다
    요구사항 변경 외에는 변경이 없도록 설계 때는 더 신중해야겠다