객체지향 패러다임 관점의 핵심
- 역할 Role
- 책임 Responsibility
- 협력 Collaboration
협력
- 협력 : 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용
- 책임 : 객체가 협력에 참여하기 위해 수행하는 로직
- 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 구성
협력
객체지향 시스템은 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협락하는 사회적인 존재다. 협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다.
- 메시지 전송 Message sending : 객체 사이의 협력을 사용할 수 있는 유일한 커뮤니케이션 수단. 객체는 다른 객체의 상세한 내부 구현에 직접 접근할수 없기 때문에 오직 메시지 전송을 통해서만 자신의 전송을 요청할 수 있다.
- 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다.
- 객체는 메시지를 처리할 방법을 스스로 선택한다. 호출부는 오직 메시지만 전송할 뿐이다.
- 자율적인 객체란 자신의 상태를 직접 관리하고 스스로의 결정에 따라 행동하는 객체다.
- 객체의 자율성을 보장하기 위해서는 필요한 정보와 정보에 기반한 행동을 같은 객체안에 모아놓아야 한다.
- 자신이 할 수 없는 일을 다른 객체에 위임하면 참여하는 객체들의 전체적인 자율성을 향상시킬 수 있다.
- 내부구현을 캡슐화 함으로써 객체를 자율적으로 만들 수 있다.
협력이 설계를 위한 문맥을 결정한다.
- 어떤 객체가 필요하다면 그 이유는 단 하나여야 한다. 그 객체는 협력에 참여하고 있기 때문이다.
- 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다.
협력이 바뀌면 객체가 제공해야 하는 행동도 바뀌어야 한다. - 객체의 상태를 결정하는 것은 행동이다.
객체의 상태는 그 객체가 행동을 수행하는데 필요한 정보가 무엇인지로 결정된다. - 상태는 객체가 행동하는 데 필요한 정보에 의해 결정된다.
행동은 협력 안에서 객체가 처리할 메시지로 결정된다.
따라서 협력은 객체를 설계하는 데 필요한 문맥 Context 를 제공한다.
책임
협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 한다.
- 책임 : 객체에 의해 정의되는 응집도 있는 행위의 집합. 객체가 유지해야 하는 정보와 수행할 수 있는 행동을 서술한 문장. 무엇을 알고 있는가와 무엇을 할 수 있는가로 구성된다.
하는 것
- 객체를 생성 하거나 계산을 수행하는 등의 스스로 하는 것
- 다른 객체의 행동을 시작시키는 것
- 다른 객체의 활동을 제어하고 조절하는 것
아는 것
- 사적인 정보에 관해 아는 것
- 관련된 객체에 관해 아는 것
- 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
일반적으로 책임과 메시지의 크기는 다르다. 책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하기 때문에 메시지보다 추상적이고 개념적으로도 더 크다. 처음에는 단순한 책임이라고 생각했던 것이 여러개의 메시지로 분할되기도 하고 하나의 객체가 수행할 수 있다고 생각했던 책임이 나중에는 여러 객체들이 협력해야만 하는 커다란 책임으로 자라는 것이 일반적이다.
객체에 얼마나 적절한 책임을 할당하느냐가 설계의 전체적인 품질을 결정한다.
책임 할당
- 정보 전문가 Information expert 패턴 : 자율적인 객체를 만드는 가장 기본적인 방법인 책임을 수행하는데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 방법
정보 전문가에게 책임을 할당하는 방법
- 시스템이 사용자에게 제공해야하는 기능인 시스템 책임을 파악한다.
- 시스템 책임을 더 작은 책임으로 분할한다.
- 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
- 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
- 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 된다.
객체지향 설계는 협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 반복적인 과정을 통해 이뤄진다. 그리고 이런 메시지가 메시지를 수신할 객체의 책임을 결정한다.
- 책임 주도 설계 Responsibility-Driven Design : 책임을 갖고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법.
메시지가 객체를 결정한다
메시지가 객체를 선택하게 해야 하는 이유
- 객체가 최소한의 인터페이스 Minimal interface를 가질수 있게 된다.
필요한 메시지가 식별될 때까지 객체의 퍼블릭 인터페이스에 어떤 것도 추가하지 않기 때문에 객체는 어플리케이션에 크지도 작지도 않은 꼭 필요한 크기의 퍼블릭 인터페이스를 가질 수 있다. - 객체는 충분히 추상적인 인터페이스 Abstract intrface를 가질 수 있게 된다.
객체의 인터페이스는 무엇을 하는지는 표현해야 하지만 어떻게 수행하는지를 노출해서는 안된다. 메시지의 외부 객체가 요청하는 무언가를 의미를 가지기 때문에 메시지를 식별하여 무엇을 수행할지 초점을 맞춰야 한다.
행동이 상태를 결정한다.
객체는 협력에 필요한 행동을 제공해야 한다. 객체를 만드는 것은 상태가 아니라 객체가 다른 객체에게 제공하는 행동이다.
객체에 행동을 먼저 정하는 것이 아니라 객체에 필요한 상태가 무엇인지 먼저 지정하면 객체의 내부 구현이 퍼블릭 인터페이스를 통해 노출되기 때문에 캡슐화를 저해한다. 객체의 내부 구현을 변경하면 퍼블릭 인터페이스도 함께 변경되고 결국 객체에 의존하는 클라이언트로 변경 영향이 전파된다. 이같이 객체 내부 구현에 초점을 맞춘 설계를 데이터 주도 설계 Data-Driven Design 라고 한다
- 캡슐화를 위반하지 않도록 구현에 대한 결정을 뒤로 미루면서 객체의 행위를 고려하기 위해서는 협력이라는 문맥안에서 객체를 생각해야 한다.
- 개별 객체의 상태와 행동이 아닌 시스템의 기능을 구현하기 위한 협력에 초점을 맞춰야만 응집도가 높고 결합도가 낮은 객체들을 창조할 수 있다.
- 상태는 단지 객체가 행동을 정상적으로 수행하기 위해 필요한 재료일 뿐이다.
- 객체가 가질 수 있는 상태는 행동을 결정하고 나서 결정할 수 있다.
- 협력이 객체의 행동을 결정하고 행동이 상태를 결정한다.
역할
역할과 협력
- 협력 : 문맥안에서 갖는 목적
- 역할 : 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합
협력을 모델링 할때는 특정한 객체가 아니라 역할에게 책임을 할당하는 것
유연하고 재사용 가능한 협력
- 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있다.
- 역할은 다른 것으로 교체할 수 있는 책임의 집합이다. (추상화를 통해 가능)
- 추상화를 하면 동일한 책임을 수행하는 역할을 기반으로 두 개의 협력을 하나로 통합할 수 있다.
객체 대 역할
객체에 관해 생각할 때 ‘이 객체가 무슨 역할을 수행해야 하는가?’ 라고 자문하는 것은 도움이 된다. 이 질문은 객체가 어떤 형태르 띠어야 하는지, 그리고 어떤 동작을 해야 하는지 집중할 수 있게 도와준다. 지금까지 객체와 역할에 대해 막연하게 이야기를 했는데, 둘의 진짜 차이는 무엇일까? 만약 동일한 종류의 객체가 하나의 역할을 항상 수행한다면 둘은 동일한 것이다. 하지만 어떤 협력에서 하나 이상의 객체가 동일한 책임을 수행할 수 있다면 역할은 서로 다른 방법으로 실행할 수 잇는 책임의 집합이 된다. 역할이란 프로그램이 실행될 때 소프트웨어 기계 장치에서 적절한 객체로 메워 넣을 수 있는 하나의 슬롯으로 생각할 수 있다. … 객체는 의미있는 역할을 정의하는 책임을 통해 어플리케이션의 기능을 담당하게 된다.
- 협력에 적합한 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주한다. 여러종류의 객체들이 참여할 수 있다면 역할로 간주한다.
- 협력을 구체적인 객체가 아니라 추상적인 역할의 관점에서 설계하면 협력이 유연하고 재사용 가능해진다.
- 역할의 가장 큰 장점은 설계의 구성 요소를 추상화 할 수 있다는 것이다.
역할과 추상화
역할은 공통의 책임을 바탕으로 객체의 종류를 숨기기 때문에 이런 관점에서 역할을 객체의 추상화로 볼 수 있다.
추상화가 가지는 장점
- 세부사항에 억눌리지 않고도 상위 수준의 정책을 쉽고 간단하게 표현할 수 있다.
추상화를 적절하게 사용하면 불필요한 세부 사항을 생략하고 핵심적인 개념을 강조할 수 있다.
역할이 중요한 이유는 동일한 협력을 수행하는 객체들을 추상화할 수 있기 때문이다. - 설계를 유연하게 만들 수 있다.
역할은 다양한 종류의 객체를 끼워넣을 수 잇는 일종의 슬롯이다.
협력 안에서 역할이라는 추상화를 이용하면 기존 코드를 수정하지 않고도 새로운 행동을 추가할 수 있다.
프레임워크나 디자인 패전과 같이 재사용 가능한 코드나 설계 아이디어를 구성하는 핵심적인 요소가 바로 역할이다.