객체지향의 사실과 오해 4장 - 역할, 책임, 협력

"우리 모두를 합친 것보다 더 현명한 사람은 없다." - Ken Blanchard

 

 

 

 

앞선 장에서 개별적인 객체의 행동,상태에 대해 살펴봤다면,

이번 장은 객체들 간의 협력에 대해 알아보려고 합니다.

 

 

1. 협력

 

A라는 사람이 B에게 도움을 요청한다.

B라는 사람도 다른사람에게 도움을 요청한다.

 

A함수가 할수 있는 일이 있고

B함수가 할수 있는 일이 있음.

 

요청(도움)을 연쇄적으로 요청하게 된다.

 

 

 

책에서 비유한 이야기를 예시로 협력의 특성을 알아보려고 합니다.

 

 

 

이상한나라의 앨리스 이야기 속 재판을 객체지향 관점에서 봤을때

 

왕, 하얀토끼, 모자 장수 - 객체이며

하트 잭을 재판하기 위해 협력중이라고 볼 수 있음.

 

    1. 누군가가 왕에게 재판을 요청

    2. 왕이 하얀 토끼에게 증인을 요청

    3. 토끼는 모자장수에게 증언을 요청

    ..

    ~

 

각각의 객체는 요청에 응답해줄 수 있는 지식과 행동방식을 가지고 있다.

그리고 요청과 응답은 객체가 수행할 책임을 정의함.

 

 

 

 

2. 책임

 

요청에 응답해 줄 수 있으면 해당 객체는 책임을 가진다고 말한다.

왕 - 재판을 수행할 책임

토끼 - 증인을 요청할 책임

모자장수 - 증언을 할 책임

 

 

 

 

"객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것"

구현할때 객체의 책임을 잘 설계하고 구현할 필요가 있다.

 

 

 

크레이그 라만의 책임의 분류 방법

    a. 객체가 무엇을 하는가

        - 객체를 생성하거나 계산하거나

        - 다른 객체의 행동을 시작하거나

 

    b. 객체가 무엇을 아는가

        - 자신이 유도하거나 계산할 수 것에 대한 지식 보유

        - 관련된 객체에 관해 안다

 

 

 

모자 장수(객체)의 경우 스스로 증인석에 입장해야 하는 책임과

자신이 알고 있는 사실을 증언해야 할 책임을 가지고 있다.

 

 

외부에서 접근 가능한 공용 서비스의 관점에서 보면

 

책임은 객체의

    a. 외부에 제공해 줄 수 있는 서비스(doing)와

    b. 외부에 제공해 줄 수 있는 정보(knowing)의 목록이다.

 

-> 책임은 객체의 공용 인터페이스(public interface) 라고 볼 수 있다.

 

 

 

 

3. 역할

 

 

모자장수 - '증인'이라는 역할을 수행

왕 - '판사'라는 역할을 수행

 

굳이 왕을 판사의 역할이라고 하는 이유

-> 역할이 재사용 가능함을 의미 -> 유연한 객체지향 설계를 하도록함.

 

 

 

책에서 언급하는 앨리스 이야기에서

요리사(증인2)가 등장 -> 역할을 재사용성을 의미

 

왕 - 재판을 수행할 책임

토끼 - 증인을 요청할 책임

요리사 - 증언을 할 책임

 

 

재판의 과정은 동일.

역할을 맡은 사람이 바뀜

 

 

'판사' - 재판을 수행할 책임

'토끼' - 증인을 요청할 책임

'증인' - 증언을 할 책임

 

 

 

대체 가능한 객체는 메세지(요청에 대한 응답)를 이해할 수 있는 객체로 한정됨

 

 

 

역할의 대체 가능성은 행위 호환성을 의미하고,

행위 호환성은 동일한 책임의 수행을 의미.

 

 

 

 

협력의 오류

 

객체가 존재하는 이유는

데이터를 저장하기 위해x

행동을 수행하며 협력에 참여하기 위해서라고 합니다.

 

-> 중요한것은 객체의 행동, 즉 책임입니다

 

그래서 프로그래밍시

객체가 협력 안에서 어떤 책임과 역할을 수행할것인지에 대해 고려하여 구현하는게 중요하다.

(클래스 간의 관계 표현에 중점을 두고 프로그래밍 하기 보다는)

 

 

왕관을 쓰고 수염을 기르고 근엄한 표정으로 왕좌에 앉아있는 왕의 모습을 구현하는 것

이런 왕의 겉모습은 중요하지 않다고 합니다.

 

중요한 부분은 -> 재판이라는 '협력'에 판사의 역할 (객체의 책임과 객체간의 협력 관계)

이런 부분을 고려하여 구현하면 좋다고 합니다.

 

 

 

객체지향 설계 기법

 

1. 책임-주도 설계 방법 (Responsibility-Driven Design)

 

협력(재판)에 필요한 책임(판사,증인)들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 어플리케이션을 설계하는 방법이라고 볼 수 있음.

 

        a. 제공 해야하는 책임을 파악

        b. 더 작은 책임으로 분할

        c. 책임을 적절한 객체에게 할당

        d. 다른 객체의 도움이 필요할 경우, 이를 책임질 적절한 객체 또는 역할 찾기

 

 

2. 디자인 패턴 (Design Pattern)

 

전문가들이 반복적으로 사용하는 해결 방법을 정의해놓은 설계 템플릿 모음이다.

특정 문제를 해결하기 위해 식별해놓은 역할, 책임, 협력의 모음이라고 볼 수 있음.

 

ex. Composite 패턴 - 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 복합 객체나 단일 객체를 동일하게 취급하는 것을 목적으로 둔 방법. 

 

Directory - File 관계 :

요청(경로 변경)의 응답 부분이 단일객체(File)인지 복합객체(Directory)인지 구분 없이 동일하게 처리한다.

 

 

 

- Component
객체(복합객체 + 단일객체)들의 공통되는 메소드를 정의 (인터페이스)

다른 Component를 추가(add)하거나 제거, 자식을 반환하는 책임을 가지고 있음.

 

- Leaf
생성된 단일 객체(File)

- Composite
Leaf객체들로 이루어져 있으며(복합객체) 컴포넌트 내 명령들을 구현한다. 

 

- Client

Component 인터페이스를 사용해 복합체 구조 내의 객체들을 조작한다.

 

 

예시 - 게임 유닛

 

Unit - 모든 유닛들이 가지는 공통 기능과 속성을 정의 (getAttackPower())

LeafUnit (단일객체) - 단일 유닛, 전사(10), 마법사(8)

GroupUnit (복합객체) - 부대1(전사2 => 20), 부대2(전사1+마법사2 => 26)

 

장점: 확장과 유연성에 좋음. 계층 구조를 효과적으로 다룸

 

 

ex. Apapter 패턴 - 프레임워크나 라이브러리 등이 바뀔때마다 수정할 필요 없도록 호환되는 인터페이스를 따로 만들어 두는것(돼지코 어댑터를 떠올려보세요..)

 

 

 

3. 테스트 주도 개발 (Test-Driven Development)

 

테스트를 먼저 작성하고 통과하는 코드를 추가하면서 어플리케이션을 완성해나가는 방법.

실제 목적은 구체적인 코드를 작성해나가면서

역할, 책임, 협력을 식별하고 역할, 책임, 협력이 적합한지 피드백 받는것.

 

 

 

 

역할, 책임, 협력을 잘 구분하고 정의해서 객체지향 프로그래밍을 할 수 있도록 합시다.