j03y14
commented
6 months ago 책임과 메세지
처음 예시책임감 분산.
책임이 불명확할 수록 어떤 객체가 도와줄 수 있는지 찾기가 어렵다.
자율적인 책임
"자율성"
책임: 요청을 처리하기 위해 객체가 수행하는 행동
자율적인 객체: 스스로의 의지와 판단에 따라 맡은 책임을 수행하는 객체
협력에 참여하는 객체가 얼마나 자율적인지가 어플리케이션의 품질을 결정한다.
자율적인 책임을 가지기 위해서
너무 구체적인 책임은 좋지 않다.
책임을 자율적으로 수행하기 위해서는 할당되는 책임이 자율적이어야 한다.
"증언하라" 라는 책임은 "목격한 장면을 떠올리고, 떠오르는 기억을 시간순으로 재구성한 후, 말로 간결하게 표현해라" 보다 자율적이다.
왕의 입장에서는 모자장수가 어떤 방식으로 증언하는지는 중요하지 않다.
너무 추상적인 책임은 좋지 않다.
"설명하라"처럼 지나치게 추상적이어서 협력의 의도를 명확하게 표현하지 못하는 것 역시 문제이다.
어떻게가 아니라 무엇을
자율적인 책임을 위해서는객체가 무엇을 해야하는가를 설명해야 한다. 어떻게 할 것인지는 자율적으로 선택할 수 있다.
책임을 자극하는 메세지
메세지가 책임을 수행하게 만드는 유일한 수단이다.
메세지와 메서드
메세지
- 메세지 이름
- 인자
메세지를 처리할 수 있다는 것은 책임이 있다는 것을 의미한다. 따라서 수신할 수 있는 메세지의 모양이 책임의 모양을 결정한다.
모자장수가 메세지를 변경하지 않는다면 책임을 수행하는 방법을 변경하더라도 왕은 알 수 없다. 메세지를 기준으로 객체의 외부와 내부가 분리된다.
메서드
메세지를 처리하기 위해 내부적으로 선택하는 방법을 메서드라고 한다.
메세지를 수신한 객체가 실행시간에 메서드를 선택할 수 있다는 사실은 다른 프로그래밍 언어와 객체지향 프로그래밍 언어를 구분짓는 특징 중 하나이다.
다형성
다형성은 서로 다른 유형의 객체가 동일한 메세지에 대해 다르게 반응하는 것을 의미한다. 객체들이 다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것을 의미한다.
송신자는 다형적인 수신자들을 구분할 필요가 없다.
송신자가 수신자에 대해 적은 정보만 알고 있어도 된다는 사실은
- 협력을 유연하게 한다.
- 협력이 수행되는 방식을 확장할 수 있다. - 수신자 관점
- 협력이 수행되는 방식을 재사용할 수 있다. - 송신자 관점
메세지의 존재가 송신자와 수신자 사이의 결합도를 낮춘다. 메세지와 메서드를 분리하는 것이 중요한게 아닐까?
메세지를 따라라
객체지향의 강력함은 객체들이 주고받는 메세지로부터 나온다.
어떤 메세지를 전송할 수 있고, 어떤 메세지를 이해할 수 있는가를 중심으로 협력 관계를 구성하는 것이 중요하다. 메세지가 객체를 선택해야 한다.
책임주도 설계 다시보기
시스템 책임을 구현하기 위해 협력 관계를 객체의 책임으로 할당한다. 도움이 필요하면 어떤 메세지가 필요한지 결정한다. 메세지를 수신하기에 적합한 객체를 선택한다. 수신자는 메세지를 처리할 책임이 있다.
what who 사이클
어떤 행위를 수행할 것인지 결정한 후에 누가 행위를 수행할지를 결정하는 것.
수신가능한 메제기마 모여 객체의 인터페이스를 구성한다.
객체 이넡페이스
경계 지점에서 서로 상호작용 할 수 있게 이어주는 방법
- 내부 구조나 방식을 몰라도 조작할 수 있다.
- 인터페이스는 변경하지 않고 내부 구성이나 작동 방식을 변경할 수 있다.
- 대상이 변경되어도 동일한 인터페이스를 제공하면 문제없이 상호작용 할 수 있다.
객체가 어떤 메세지를 수신할 수 있느냐가 어떤 책임을 수행할 수 있느냐와 어떤 인터페이스를 가질 것인지를 결정한다.
인터페이스와 구현의 분리
- 좀 더 추상적인 인터페이스: "증언하라"
- 최소 인터페이스
- 외부에서 사용하지 않을 것은 노출하지 마라.
- 인터페이스와 구현 사이에는 차이가 있다.
객체 설계의 핵심은 객체를 두가지 분리된 요소로 분할해 설계하는 것이다. 인터페이스와 구현을 분리한다.
객체의 모든 것이 공개되어 있다면 부분의 수정에 의해서 많은 부분이 수정된다. 변경에 대한 안전지대를 만드는 것이 인터페이스와 구현을 분리하는 것이다.
분리를 토애서 객체를 자율적인 존재로도 만들 수 있다.
책임의 자율성이 협력의 품질을 결정한다.
어떤 협력이 더 나은 설계라고 부를 수 있는 기준은 무엇일까?
어떤 협력이 다른 협력보다 이해하기 쉽고 변경에 유연하기 때문이다. 책임이 자율적일 수록 협력이 이해하고 유연하게 변경 가능하다.
- 자율적인 책임은 협력을 단순하게 만든다.
- 자율적인 책임은 모자장수의 외부와 내부를 명확하게 분리한다.
- 책임이 자율적인 경우 책임을 수행하는 내부적인 방법을 분리해도 외부에 영향을 미치지 않는다.
- 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있게 한다.
- 객체가 수행하는 책임들이 자율적일 수록 객체의 역할을 이해하기 쉬워진다.
kkirico
5장 책임과 메시지
훌륭한 객체지향의 세계는 명확하게 정의된 역할과 책임을 지닌 객체들이 상호 협력하는 세계다.
자율적인 책임
설계의 품질을 좌우하는 책임
자율적인 객체는 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체를 의미한다.
자신의 의지에 따라 증언할 수 있는 자유
객체의 책임이 자율적어야 한다. 너무 상세한 수준의 책임은 객체의 자율성을 저해한다.
너무 추상적인 책임
협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것 역시 문제다.
문맥에 가장 적합한 책임을 선택해야한다.
‘어떻게’가 아니라 ‘무엇을’
자율적인 책임의 특징은 객체가 어떻게 하는지가 아니라 무엇을 하는지 설명한다.
책임을 자극하는 메시지
메시지는 객체로 하여금 자신의 책임, 즉 행동을 수행하게 만드는 유일한 방법이다.
메시지와 메서드
메시지
메시지는 두 부분으로 구성된다.
메시지 이름
메시지 인자
증언하라(어제, 왕국)메시지 전송은 수신자와 메시지의 조합이다.
모자장수, 증언하라(어제, 왕국)메시지는 객체가 협력하기 위한 유일한 의사소통 수단이다.
객체는 메시지를 처리하기 위한 방법을 자율적으로 선택할 수 있다.
외부의 객체는 메시지에 관해서만 볼 수 있다.
이를 통해 객체의 외부와 내부가 분리된다.
메서드
메시지를 처리하기 위해 내부적으로 선택하는 방법을 메서드라고 한다.
메서드는 클래스안에 포함된 함수 또는 프로시저를 통해 구현된다.
메시지를 수신한 객체가 메서드를 선택하는 것은 객체지향 프로그래밍 언어의 특징이다.
프로시저 호출에 대한 실행코드를 컴파일 타임에 결정하는 절차적인 언어와 확연히 구분된다.
다형성
서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는것을 의미한다.
송신자의 입장에서 다형적인 수신자들을 구별할 필요가 없다.
다형성은 수신자의 종류를 캡슐화한다.
송신자와 수신자를 약하게 연결하는 메시지
메시지는 송신자와 수신자 사이의 결합도를 낮춤으로서 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다.
메시지를 따라라
객체지향의 핵심, 메시지
객체지향의 강력함은 클래스가 아니라 객체들이 주고 받는 메시지에서 나온다.
애플리케이션을 살아있게 만드는 것은 클래스가 아니라 객체다.
그리고 이런 객체들의 윤곽을 결정하는 것이 메시지이다.
협력 관계 속에서 다른 객체에게 무엇을 제공해야 하고 다른 객체로부터 무엇을 얻어야 하는가라는 관점에서 접근할 때만 훌륭한 책임을 수확할 수 있다.
책임 주도 설계 다시 살펴보기
적절한 책임을 적절한 객체에게 할당하면서 메시지를 기반으로 협력하는 객체들의 관계를 발견하는 과정이다.
애플리케이션이 수행하는 기능을 시스템의 책임으로 본다.
협력관계를 시작할 적절한 객체를 찾아, 시스템의 책임을 객체의 책임으로 할당한다.
객체가 책임을 완수하기 위해 다른 객체의 도움이 필요하다면 도움을 요청하기 위해 어떤 메시지가 필요한지 결정한다.
메시지를 수신하기에 적합한 객체를 선택한다.
→ 메시지가 수신자의 책임을 결정한다.
what/who 싸이클
어떤 객체가 어떤 특성을 가지고 있다고 해서, 반드시 그와 관련된 행위를 수행할 것이라고 가정해선 안된다.
행위를 먼저 식별한 후에 행위를 수행할 객체를 결정해야 한다.
묻지 말고 시켜라
어떤 메시지가 필요한지 먼저 고민했다면, 송신자와 수신자가 느슨하게 결합된다.
송신자는 수신자가 어떤 객체인지 모르기 때문에 수신자 객체에 대해 꼬치꼬치 캐물을 수 없다.
전송한 메시지를 잘 처리할 것이라고 믿고 메시지를 전송한다.
객체가 다른 객체에 대해 자세히 묻는 다는 것은 메시지를 전송하기 전에 객체가 가져야하는 상태에 대해 너무 많이 고민한다는 것을 의미한다.
→ 어떻게 에서 무엇으로 전환하면 객체 인터페이스의 크기를 감소시킨다.
→ 외부에서 해당 객체에 의존하는 부분을 줄일 수 있다.
메시지를 믿어라
메시지를 이해할 수만 있다면 다양한 타입의 객체로 협력 대상을 자유롭게 교체할 수 있기 때문에 설계가 좀 더 유연해진다.
객체 인터페이스
인터페이스
개발자들은 미리 약속된 애플리케이션 프로그래밍 인터페이스를 통해 다른 사람이 작성한 코드와 상호작용 한다.
메시지가 인터페이스를 결정한다.
공용 인터페이스
인터페이스는 외부에서 접근 가능한 공개된 인터페이스와 내부에서만 접근할 수 있는 감춰진 인터페이스로 구성된다.
메시지 송신자가 다른 객체인지 객체 자신인지 에 따라 구분한다.
책임, 메시지 그리고 인터페이스
객체는 자율적이어야한다.
메시지와 메서드의 구분은 객체를 외부 내부로 분리하고, 다형성을 보장한다.
객체가 어떤 메시지를 수신할 수 있냐가 인터페이스를 결정한다.
인터페이스와 구현의 분리
객체 관점에서 생각하는 방법
구현
내부 구조와 작동 방식을 의미한다.
객체의 내부와 외부를 분리하는 것 = 객체의 공용 인터페이스와 구현을 분리하라
인터페이스와 구현의 분리 원칙
훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용이 가능한 객체를 의미한다.
변경해도 무방한 안전 지대(구현)와 변경했을 경우 외부에 영향을 미치는 위험 지대(인터페이스)를 구분하라
캡슐화
상태와 행위의 캡슐화
객체는 상태와 행동을 하나의 단위로 묶는 자율적인 실체이다.
이 관점에서의 캡슐화를 데이터 캡슐화 라고 한다.
객체가 자율적이기 위해서 자기 자신의 상태를 스스로 관리하게 한다.
사적인 비밀의 캡슐화
번경이 빈번하게 일어나는 불안정한 비밀(구현과 세부사항)을 인터페이스 뒤로 숨긴다.
외부의 객체는 공용 인터페이스에만 의존하고, 구현 세부 사항에 직접 의존해서는 안된다.
책임의 자율성이 협력의 품질을 결정한다.
객체의 책임이 자율적일 수록 이해하기 쉬워지고 유연하게 변경할 수 있게 된다.
자율적인 책임은 협력을 단순하게 만든다.
세부 사항들을 무시하고, 의도를 드러내는 하나의 문장으로 표현함으로써 협력을 단순하게 만든다. 책임이 적절하게 추상화 된다.
자율적인 책임은 객체의 내부와 외부를 명확하게 분리한다.
요청하는 객체가 몰라도 되는 세부 구현이 객체 내부로 캡슐화된다.
책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
변경에 의해 수정되어야 하는 범위가 좁아지고 명확해진다. → 변경의 파급효과가 객체의 내부로 캡슐화 되기 때문에 두 객체간의 결합도가 낮아진다.
자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
협력이 좀 더 유연해지고 다양한 문맥에서 재활용 될 수 있다.
설계가 유연해지고 재사용성이 높아진다.
객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.
객체의 존재 이유를 명확하게 표현할 수 있다. 객체는 동일한 목적을 달성하는 강하게 연관된 책임으로 구성된다.
객체의 응집도를 높은 상태로 유지하기 쉬워진다.