2장 이상한 나라의 객체(3) - 기계로서의 객체

기계로서의 객체

 

 

객체지향의 세계를 창조하는 개발자들의 주된 업무는

객체의 상태를 조회하고

객체의 상태를 변경하는 것 이다.

 

일반적으로 객체의 상태를 조회하는 작업을 쿼리 라고 하고

객체의 상태를 변경하는 작업을 명령 이라고 한다.

 

객체가 외부에 제공하는 행동의 대부분은 쿼리와 명령으로 구성된다.

 

버트란드 마이어는 객체를 기계에 비유해서 설명하고 있다.

마이어가 제시한 기계로서의 객체는 기계를 분해하지 않는 이상 내부를 직접 볼 수 없다.

대신 외부에 부착된 사각형과 원형의 버튼을 이용해서만 상호작용할 수 있다.

 

아래는 기계 은유를 이용한 앨리스 객체이다.

기계은유를 통한 앨리스 객체

 

사각형 버튼 음료 마시기, 케이크 먹기, 부채질 하기, 버섯 먹기, 문 통화하기 는

기계의 상태를 변경하는 것으로, 앨리스의 키 나 위치를 변경시킨다.

 

원형 버튼 키와 위치는 기계의 상태를 디스플레이 창에 출력한다.

 

사용자가 기계의 버튼을 눌러 상태를 변경하거나 상태 조회를 요청하는 것은 메세지를 전송하는 것과 유사하다.

사용자가 버튼을 누르지만 어떤 방식으로 동작할지는 기계 스스로 결정한다.

이것은 전달된 메세지에 따라 스스로 결정하는 자율적인 객체의 특성을 묘사한다.

 

결국, 사각형 버튼은 명령을, 원형 버튼은 쿼리를 의미하게 된다.

명령과 쿼리는 객체가 외부에 제공하는 행동이다.

중요한 것은 명령 버튼과 쿼리 버튼 이외의 다른 방법을 통해서는 앨리스 기계를 사용할 수 없다.

 

즉, 사용자는 객체가 제공하는 명령 버튼과 쿼리 버튼으로 구성된 인터페이스를 통해서만 객체에 접근할 수 있다.

이와 같은 기계 은유는 객체 캡슐화를 직관적이고 시각적으로 묘사한다.

 

객체는 버튼에 의해 유발되는 행동에 의해서만 접근 가능하며,

상태와 행동이 하나의 단위로 캡슐화된다는 객체의 정의를 표현한다.

 

 

기계 은유는 객체의 식별자 또한 효과적으로 설명한다.

 

상태는 동일하나 구분 가능한 두 객체

두 기계 모두 디스플레이 창에 동일한 숫자 130을 표시하고 있다.

또한, 동일한 행동을 제공하고 현재의 시점에서 상태 역시 동일하다.

하지만 두 기계를 보는 모든 사람들은 두 기계를 구분된 별개의 객체로 인식한다.

 

이것은 객체가 상태와 무관하게 구분 가능한 식별자를 가진다는 것을 의미한다.

 

 

객체 간의 메세지를 통한 협력 또한 기계 은유를 사용하면 직관적으로 이해할 수 있다.

협력하는 앨리스 기계와 음료 기계

왼쪽은 앨리스 객체이며, 오른쪽은 음료 객체이다.

 

사용자가 음료 마시기 버튼을 눌렀다고 가정해보자.

앨리스 기계는 내부적으로 키 상태를 작게 변경한 후, 링크를 통해 음료 기계에 마셔지다 버튼이 눌려지도록 요청을 전송한다.

링크를 통해 연결된 두 객체가 메세지 전송을 통해 협력하고 있다.

 

 

---

 

행동이 상태를 결정한다

 

 

객체지향에 갓 입문한 사람들이 빠지는 함정은

객체에 필요한 상태가 무엇인지 결정하고, 그 상태에 필요한 행동을 결정한다 는 것이다.

 

이와 같은 방법은 설계에 나쁜 영향을 미친다.

 

1. 상태를 먼저 결정할 경우 캡슐화가 저해된다.

상태에 초점을 맞출 경우 상태가 내부로 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되버릴 확률이 높아진다.

 

2. 객체를 협력자가 아닌 고립된 섬으로 만든다.

객체가 필요한 이유는 다른 객체와 협력하기 위함인데, 상태를 먼저 고려하는 방식은 협력에 적합하지 못한 객체를 창조하게 된다.

 

3. 객체의 재사용성이 저하된다.

객체의 재사용성은 다양한 협력에 참여할 수 있는 능력에서 나온다.

상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기 때문에 재사용성이 저하된다.

 

이에 따라 객체가 적합한지를 결정하는 것은 객체의 상태가 아니라 행동이다.

결과적으로 우리가 애플리케이션 안에서 어떤 행동을 원하느냐가 어떤 객체가 적합한지를 결정한다.

객체의 적합성을 결정하는 것은 상태가 아니라 객체의 행동이다.

 

객체지향 설계는 애플리케이션에 필요한 협력을 생각하고,

협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다.

행동을 결정한 후에야 행동에 필요한 정보가 무엇인지 고려하며, 이 때 필요한 상태가 결정된다.

 

협력 안에서 결국 객체의 행동은 객체가 협력에 참여하면서 완수해야하는 책임을 의미한다.

따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야한다. (책임-주도 설계)

 

 

---

 

은유와 객체

 

의인화

 

현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은 무엇일까?

현실 속 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다는 것이다.

 

소프트웨어 객체를 창조할 때, 우리는 결코 현실 세계의 객체를 모방하지 않는다.

오히려 현실 세계와는 전혀 다른 특징을 부여하는 것이 일반적이며, 현실 객체가 가지지 못한 능력을 부여한다.

 

레베카 워프스브록은 현실의 객체보다 더 많은 일을 할 수 있는 소프트웨어 객체의 특징을 의인화 라고 한다.

 

소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다.

현실의 모습을 참조할 뿐, 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다.

또한, 객체지향의 세계는 현실의 추상화가 아니다.

오히려 객체지향 세게의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.

 

 

은유

 

그렇다면 객체지향의 세계와 현실 세계 사이에는 전혀 상관이 없는 것 일까?

그렇지는 않다. 다만 모방이나 추상화의 수준이 아닌 다른 관점에서 유사성을 가지고 있다.

현실 세계와 객체지향 세계 사이의 관계를 좀 더 명확하게 설명할 수 있는 단어는 은유다.

 

은유란 실제로는 적용되지 않는 한 가지 개념을 이용해 다른 개념을 서술하는 대화의 한 형태이다.

은유의 본질은 한 종류의 사물을 다른 종류의 사물 관점에서 이해하고 경험하는 데 있다.

 

우리는 일상에서 은유를 사용한다.

"그 여자는 양 같아요" => 순한 양을 이용한 성격표현

"그 남자는 사자 같아요" => 사나운 사자를 이용한 성격표현

 

이것은 현실 객체와 소프트웨어 객체의 관계와 일치한다.

현실 속의 객체의 의미 일부가 소프트웨어 객체로 전달되기 때문에 프로그램 내의 객체는 현실 속의 객체에 대한 은유다.

현실 속의 전화기는 스스로 전화를 걸 수 없지만, 전화기의 개념을 이용해 객체를 묘사하면 그 객체가 전화를 걸 수 있다는 사실을 쉽게 이해하고 기억할 수 있다.

 

은유는 표현적 차이 또는 의미적 차이 라는 논점과 관련성이 깊다.

여기서 차이는 소프트웨어에 대해 사람들이 생각하는 모습과 실제 소프트웨어의 표현 차이를 의미하며, 실제 객체의 이름을 소프트웨어 객체의 이름에 사용하면 소프트웨어의 구조를 쉽계 예측할 수 있다.

이러한 은유를 효과적으로 사용하면 표현적 차이를 줄여, 이해하기 쉽고 유지보수가 용이한 소프트웨어를 만들 수 있다.

이 때문에 현실 세계인 도메인에서 사용되는 이름을 객체에 부여하라고 가이드한다.

 

 

이상한 나라를 창조하라

 

객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다.

객체의 특성을 상기시킬 수 있다면 현실 속의 객체의 이름을 이용해 객체를 묘사하라.

그렇지 않다면 깔끔하게 현실을 무시하고 자유롭게 새로운 세계를 창조하라.