02 이상한 나라의 객체 -3

기계로서의 객체

버트란 마이어의 은유 표현

객체 지향 세계에서 주된 업무는 객체 상태의 상태를 조회하고, 객체의 상태를 변경하는 것

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

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

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

 

기계로서의 객체라는 비유의 의미란 기계의 부품은 단단한 금속 외피 안에 감춰져 있어 분해하지 않는한 기계의 내부를 직접 볼 수 없다. 그저 외부에 노출된 버튼과 같은 인터페이스를 통해서만 상호작용할 수 있다.

 

둥근 버튼은 디스플레이에 현재 상태 정보를 알려준다. 쿼리

사각 버튼은 상태 변경을 한다. 명령

버튼을 누르는 행위는 메시지를 전송하는 것과 같다. 요청을 처리하는 것은 기계가 자율적으로 판단한다.

기계와 통신은 전적으로 기계가 외부로 노출한 인터페이스로만 이뤄진다. 캡슐화

두 기계 상태가 동일하더라도 상태(130)와 무관하게 구분이 가능하다.

이것은 구분 가능한 식별자를 가진다는 것을 의미한다.

앨리스 기계에 음료를 마시다 버튼을 눌렀다고 가정하면

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

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

 

 

 

 

행동이 상태를 결정한다.

상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 안좋다.

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

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

객체가 필요한 이유는 애플리케이션 문맥 내에서 다른 객체와 협력하기 위함이다.

셋째, 객체의 재사용성이 저하된다.

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

 

행동에 초점을 맞춰야 협력에 참여할 수 있다.

객체는 다른 객체와 협력하기 위해 존재한다. 행동은 객체가 협력에 참여할 수 있는 유일한 방법이다.

따라서 상태가 아니라 행동에 초점을 맞춰 객체를 설계해야한다.

 

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

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

협력이라는 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도높고 재사용 가능한 객체를 만들 수 있게 한다.

 

행동이 상태를 결정한다.

 

 

 

은유와 객체

의인화

현실 객체와 소프트웨어 객체 사이 가장 큰 차이는

현실 속 수동적 존재가 소프트웨어 속에서는 능동적 존재가 된다는 것이다.

 

일반적으로 현실 세계의 객체에 필요한 부분만을 추상화하여 가상의 객체를 만든다고 한다.(모방)

실제로 소프트웨어 안에 창조하는 객체에게 현실 세계의 객체와는 전혀 다른 특징을 부여하는 것이 일반적이다.

즉, 소프트웨어 객체가 현실 객체의 부분적인 특징을 모방하는 것이 아니라 현실 객체가 가지지 못한 추가적인 능력을 보유하게 된다.

 

예시

현실 속 트럼프 카드는 스스로 뒤집거나, 말을 할 수 없다. 계좌는 스스로 금액을 이체할 수 없다.

 

객체지향 세계를 구축할 때 현실에서 가져온 객체들은 현실 속에서는 할 수 없는 어떤 일이라도 할 수 있는 전지전능한 존재가 된다.

 

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

 

객체는 무생물이거나 심지어는 실세계의 개념적인 개제로 모델링될 수도 있지만, 그것들은 마치 우리가

현실 세계에서 에이전트로 행동하는 것처럼 시스템 안에서 에이전트처럼 행동한다. 객체가 현실 세계의

대상보다 더 많이 안다는 것이 모순처럼 보일 수도 있다. 결국, 인간이라는 에이전트 없이 현실의 전화는

서로에게 전화를 걸지 않으며 색은 스스로 칠하지 않는다. 일상적인 체계에서는 어떤 사건이 일어나기

위해 반드시 인간 에이전트가 필요한 반면 객체들은 그들 자신의 제계 안에서 [능동적이고 자율적인] 에

이전트다.

의인화의 관점에서 소프트웨어를 생물로 생각하자. 모는 생물처럼 소프트웨어는 태어나고, 삶을 영위하

고, 그리고 죽는다[Wirfs-Brock 1990].

 

심지어 현실 세계에는 존재조차 하지 않는 것들도 소프트웨어 안에서는 생생한 생명을 가진 존재로 재탄생한다.

 

소프트웨어 상에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실을 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다.

객체지향의 세계는 현실의 추상화가 아니다. 오히려 객체지향 서계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.

 

 

은유

객체지향의 세계와 현실 세계 사이에는 전혀 상관이 없는 것인가?

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

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

 

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

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

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

 

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

여기서 차이는 소프트웨어에 대해 사람들이 생각하는 모습과 실제 소프트웨어의 표현 사이의 차이를 의미한다.

은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉡게 예측할 수 있다.

이런 이유로 현실 시계 도메인에서 사용되는 이름을 객체에게 부여하라고 객체지향 지점서에서 가이드하는 것이다.

 

 

이상한 나라를 창조하라

객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다.(기존 객체지향 추상화 개념)

단지 이상한 나라를 창조하기만 하면 된다.

현실을 닮아야 한다는 어떤 제약이나 구속도 없다.

여러분이 창조한 객체의 특성을 상기시킬 수 있다면 현실 속의 객체의 이름을 이용해 객체를 묘사하라.(은유) 그렇지 않다면 깔끔하게 현실을 무시하고 자유롭게 여러분만의 새로운 세계를 창조하기 바란다. 앨리스를 매혹시킨 이상한 나라가 그런 것 처럼 말이다.