0.개요

핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것

객체를 상태(state), 행동(behavior), 식별자(identity)를 지닌 실체로 보는 것이 가장 효과적 값과 객체의 가장 큰 차이점은 값은 식별자를 가지지 않지만 객체는 식별자를 가진다는 점. 값은 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교하고, 객체는 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교해야 한다.

행동을 먼저 결정하고 상태를 나중에 결정해야 한다.

객체가 협력을 위해 어떤 책임을 지녀야 하는지를 결정하는 것이 객체지향 설계의 핵심

객체는 자신의 상태를 스스로 관리하는 자율적인 존재

역할, 책임, 협력

코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환해야 한다. 현실 세계에서는 사람이 직접 주문 금액을 계산하지만 소프트웨어 세계에서는 주문 객체가 자신의 금액을 계산한다. 현실 속 객체의 의미 일부가 소프트웨어 객체로 전달되기 때문에 프로그램 내의 객체는 현실 속의 객체에 대한 은유다. 비록 현실 속의 전화기는 스스로 전화를 걸 수 없다고 하더라도 우리가 익히 알고 있는 현실의 전화기라는 개념을 이용해 소프트웨어를 묘사하면 그 객체가 전화를 걸 수 있다는 사실을 쉽게 이해하고 기억할 수 있게 된다. 우리가 애플리케이션 안에서 어떤 행동을 원하는냐가 어떤 객체가 적합한지를 결정한다. 객체의 적합성을 결정하는 것은 상태가 아니라 객체의 행동이다. 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만 하면 된다. 현실을 닮아야 한다는 어떤 제약이나 구혹도 없다.

추상화의 목적은 복잡성을 이해하기 쉬운 수준으로 단순화하는 것

  1. 공통점은 취하고 처이점은 버린다.
  2. 중요 부분을 가종하기 위해 불필요한 세부 사항을 제거한다.

상세한 수준의 책임은 증언이라는 협력의 최종 목표는 만족시킬지 몰라도 모자 장수가 누려야 하는 선택의 자유를 크게 훼손하고 만다.

자율적인 책임의 특징은 객체가 어떻게 해야 한느가가 아니라 무엇을 해야하는가를 설명한다는 것

객체가 다른 객체에 접근할 수 있는 유일한 방법은 요청을 전송하는 것뿐

객체지향은 '자율적인' 객체들의 협력이다. 어떤 사물이 자신의 행동을 스스로 결정하고 책임진다면 우리는 그 사물을 자율적인 존재라고 말한다.

다형성 : 동일한 메시지에 대해 서로 다른 유형의 객체가 각기 다르게 반응하는 것 메시지(message) vs 메서드(method) 다형성은 메시지 송신자의 관점에서 동일한 역할을 수행하는 다양한 타입의 객체와 협력할 수 있게 한다. 다형성은 동일한 역할을 수행할 수 있는 객체들 사이의 대체 가능성을 의미한다. 다형성은 객체들의 대체 가능성을 이용해 설계를 유연하고 재사용 가능하게 만든다. 다형성은 수신자의 종류를 캡슐화한다. 객체 지향이 유연하고 확장 가능하고 재사용성이 높은 것은 다형성에 있다. 왕은 증언하라 라는 메시지를 전송할 수 있지만, 수신자의 구체적인 타입에 대해서는 알지 못한다. 모자 장수가 될지, 엘리스가 될지, 요리사가 될지 메시지는 송신자와 수신자 사이의 결합도를 낮춤으로써 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다. 객체지향에서 객체들이 서로 협력하기 위해 사용할 수 있는 유일한 방법은 메시지를 전송하는 것이다.

클래스가 코드를 구현하기 위해 사용할 수 있는 중요한 추상화 도구인 것은 사실이지만 객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로부터 나온다. 앱을 살아있게 만드는 것은 클래스가 아니라 객체이고, 이런 객체들의 윤곽을 경정하는 것이 바로 객체들이 주고 받는 메시지다. 클래스는 단지 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위해 사용할 수 있는 추상화 도구일 뿐. 정적인 클래스들의 집합이 아닌 메시지를 주고받는 동적인 객체들의 집합으로 바라보는 것에서 시작. 클래스에 담길 객체들의 공통적 행위와 속성을 포착하기 위해서는 먼저 협력하는 객체들의 관점에서 시스템을 바라봐야 한다. 메시지가 수신자의 책임을 결정한다. What/Who 사이클 : 어떤 행위(what, 메시지)를 수행할 것인지를 결정한 후에 누가(who, 객체) 그 행위를 수행할 것인지를 결정해야 한다. 일단 메시지가 결정된 후에야 이 메시지를 처리할 객체를 선택한다. 메시지를 결정하는 시점에는 객체가 정해지지 않음 -> 객체 내부 상태 볼수 없음 -> 메시지 수신자의 캡슐화를 증진 and 송신자와 수신자가 느슨하게 결합 '묻지 말고 시켜라' 인터페이스 : 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있게 이어주는 방법이나 장치 메시지가 인터페이스를 결정한다. 객체가 다른 객체와 상호작용할 수 있는 유일한 방법은 '메시지 전송'이다.

인터페이스와 구현의 분리 송신자와 수신자가 구현 부분이 아닌 느슨한 인터페이스에 의해서만 결합되도록 한다. 캡슐화를 '정보 은닉'이라고도 불린다. 요청하는 객체가 몰라도 되는 부분이 객체 내부로 캡슐화 되기 때문에 인터페이스와 구현이 분리된다.

객체에게 책임을 할당하고 인터페이스를 결정할 때에는 가급적 내부의 구현에 대한 어떤 가정도 하지 말아야 한다. 먼저 객체가 어떤 책임을 수행해야 하는지를 결정한 이후에 책임을 수행하는 데 필요한 객체의 속성을 결정하라.

자율적인 책임은 내부와 외부를 명확하게 분리한다.

손님이 메뉴판을 통해 커피를 주문할 때, 현실에서는 메뉴판은 수동적인 입장이지만

앨리스와 음료

앨리스와 트럼프들

왕과 토끼와 증인들의 재판

지하철 노선도

안정적인 구조와 불안정한 기능 안정적인 구조 : 사용자나 이해관계자들이 도메인에 관해 생각하는 개면과 개념들 간의 관계로 표현(기능을 수집하고 표현하기 위한 기법 : 유스케이스 모델링)

  • 도메인 모델
  • 도메인을 담을 수 있는 객체지향
  • 불안정한 기능을 담을 수 있는 도메인 모델 불안정한 기능 : 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현(구조를 수집하고 표현하기 위한 기법을 도메인 모델링)
  • 유스케이스
    • 유스케이스는 단지 사용자가 바라보는 외부의 관점만을 표한한다.