요약 : 현실세계와 객체지향 세계 사이의 관계는 모방이나 추상화의 수준이 아닌 은유(metaphor)의 관점에서 표현한다.
객체지향 패러다임은 지식을 추상화하고 추상화한 지식을 객체안에 캡슐화함으로서 실세계 문제에 내재된 복잡성을 관리하려고 한다. 객체를 발견하고 창조하는 것은 지식과 행동을 구조화하는 문제다. - 레베카 워프스브룩
객체지향과 인지 능력
- 우리는 왜 세상을 더 작은 객체로 분리하여 보고자 할까
- 복잡성을 극복하기 위해
- 우리는 좀 더 단순한 객체들로 주변을 분해함으로서 자신이 몸담고 있는 세상을 이해하려고 노력한다.
- 하지만 객체와 현실의 유사성은 여기까지.
- 객체지향 패러다임의 목적은 현실 세계를 기반으로 새로운 세계를 창조하는 것.
- 소프트웨어 세계에서는 전등 스스로 불을 끈다.
- 자신의 상태를 변화시키는 것은 객체 스스로 해야하므로
1. 객체의 정의와 개념 정리
이 책에서의 정의
객체는 식별 가능한 개체 또는 사물. 자동차처럼 만질 수 있는 구체적인 사물읠 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현된다.
1) 상태
- 왜 상태가 필요할까?
ex) 자판기에 충분한 금액을 투입하기 전에는 원하는 음료를 선택할 수 없다. - 상태와 프로퍼티
객체의 상태를 구성하는 모든 특징을 통틀어 객체의 프로퍼티(property)라고 한다.
예를들어보자. 사람이 물을 들고 있다고 하면, 사람과 물은 각각 객체이지만, 물은 사람의 상태를 구성하는 하나의 특성이 된다.
즉 사람이라는 객체는 수분이라는 프로퍼티를 가지고, 물은 양이라는 프로퍼티를 가진다.
이때 프로퍼티는 변경되지 않고 고정되므로 '정적'이지만, 프로퍼티 값(property value)은 '동적'이다.
또한 위와같이 객체와 객체 사이의 의미있는 연결을 link라고 함. 이게 없으면 요청 보내고 받을 수 없다.
정리하면
상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분할 수 있다.
여기서 객체는 자율적인 존재라는 점을 명심해야한다. 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 스스로 자신의 상태를 책임져야 하고, 그렇기에 간접적으로 객체의 상태를 변경하거나 조회할 수 있는 방법이 필요. 이 시점에서 행동이 등장.
2) 행동
-
상태와 행동
객체가 취하는 행동은 객체 자신의 상태를 변경시킨다. 객체의 행동에 의해 객체의 상태가 변경된다는 것은 행동이 부수효과를 초래한다는 것을 의미.
이때 객체의 행동은 객체의 상태를 변경시키지만 행동의 결과는 객체의 상태에 의존적. -
즉, 어떤 행동의 성공 여부는 이전에 어떤 행동들이 발생했는지에 따라 바뀐 상태에 영향을 받는다.
- 행동의 순서 또한 중요하다는 의미
이것은 상태라는 개념을 통해 행동을 다음 두 가지 관점에서 서술할 수 있음을 의미
(1) 상호작용이 현재의 상태에 어떤 방식으로 의존하는가
(2) 상호작용이 어떻게 현재의 상태를 변경시키는가
- 행동의 순서 또한 중요하다는 의미
-
협력과 행동
객체가 다른 객체와 협력하는 유일한 방법은 다른 객체에 요청을 보내는 것(즉, 메세지를 통해서만 의사소통).
객체가 어떤 행동을 하도록 만드는 것은 객체가 외부로부터 수신한 메세지이다.
정리하면행동이란 외부의 요청 또는 수신된 메세지에 응답하기 위해 동작하고 반응하는 활동. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메세지를 전달할 수 있음. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야한다.
-
상태 캡슐화
현실 세계에서는 음료의 양을 줄여 상태를 변경시키는 주체는 물을 마시는 사람.
하지만 객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재. 수분을 증가시키는 것이 사람 자신인 것처럼 물 객체의 양을 줄이는 것은 물 자신이어야 함.
이 협력 관계를 그림으로 표현하면 아래와 같다.
사람 객체든 다른 객체든 메세지 송신자는 메세지 수신자의 상태 변경에 대해서는 전혀 알지 못한다.
이것이 캡슐화의 의미이다. 객체는 상태를 캡슐 안에 숨겨두고 외부로 노출하지 않는다. 노출하는 것은 오직 행동뿐이다.
상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 결과적으로 객체의 자율성을 높이며, 협력을 단순하고 유연하게 만들어준다.
3) 식별자
- 객체를 서로 구별할 수 있도록 해주는 특정한 프로퍼티를 말한다.
값과 객체의 가장 큰 차이점은 값은 식별자를 가지지 않지만 객체는 식별자를 가진다는 것.
값이 같은지 여부는 상태가 같은지를 통해 판단. -> 이러한 성질을 동등성(equality)라고 한다.
상태를 이용해 동등성을 판단할 수 있는 이유는 값의 상태가 변하지 않기 때문이다(값은 불변상태를 가진다고 말함).
반면 객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다. 따라서 순간 타입이 동일한 두 객체의 상태가 완전히 같더라도 두 객체는 독립적인 별개의 객체로 다뤄야 함.
-> 식별자를 기반으로 객체가 같은지를 판단해야 함. -> 이러한 성질을 동일성(identical)이라고 함.
정리하면식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티이다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교한다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교할 수 있다.
뭐.. 객체 주소값 혹은 DB의 id값등이 있나?
2. 행동이 상태를 결정한다.
객체에 필요한 상태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정하는 것은 설계에 안좋은 영향을 끼친다.
1) 상태를 먼저 결정할 경우 캡슐화가 저해된다.
- 상태에 초점을 맞추면 공용 인터페이스에 노출되어버릴 확률이 높아짐.
2) 객체를 협력자가 아닌 고립된 섬으로 만든다.
- 객체가 필요한 이유는 앱의 문맥 내에서 다른 객체와 협력하기 위해서임.
- 상태를 먼저 고려하면 협력이라는 문맥에서 멀리 벗어난 채로 객체를 설계하게 됨으로서 협력에 적합하지 못한 객체를 창조하게 된다.
3) 객체의 재사용성이 저하된다.
- 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어려우므로 재사용성이 저하될 수 밖에 없음.
객체가 적합한지를 결정하는 것은 그 객체의 상태가 아닌 행동이다.
3. 은유와 객체
1) 두번째 도시전설
- 객체지향 세계는 현실 세계의 단순한 모방이 아니다. 소프트웨어 상품은 실제 세계의 상품이 하지 못하는 가격 계산과 같은 행동을 스스로 수행할 수 있다. 이는 소프트웨어 상품이 실제 세계의 상품을 단순화하거나 추상화한 것이 아니라 특성이 전혀 다른 어떤 것임을 의미.
- 모방과 추상화라는 개념만으로는 현실 객체와 소프트웨어 객체 사이의 관계를 깔끔하게 설명하지 못함.
2) 의인화
- 현실속 트럼프 카드는 스스로 뒤집을 수도, 말을 할 수도, 걸을 수도 없다. 하지만 객체지향 세계를 구축할 때 현실에서 가져온 객체들은 현실속에서 할 수 없는 어떤 일이라도 할 수 있는 존재가 됨.
- 레베카 워프스브록은 현실의 객체보다 더 많은 일을 할 수 있는 소프트웨어 객체의 특징을 의인화(anthropomorphism)이라고 부른다.
객체는 무생물이거나 심지어는 실세계의 개념적인 개체로 모델링될 수도 있지만, 그들은 마치 우리가 현실 세계에서 에이전트로 행동하는 것처럼 그들의 시스템 안에서 에이전트처럼 행동한다. (…) 일상적인 체계에서는 어떤 사건이 일어나기 위해 반드시 인간 에이전트가 필요한 반면 객체들은 그들 자신의 체계 안에서 능동적이고 자율적인 에이전트다. 의인화의 관점에서 소프트웨어를 생물로 생각하자. 모든 생물처럼 소프트웨어는 태어나고, 삶을 영위하고, 그리고 죽는다
[Wirfs-Brock 1990]
3) 은유
(1) 은유란?
- 그렇다면 객체지향의 세계와 현실 세계 사이에는 전혀 상관이 없을까? 그렇지는 않다.
다만 모방이나 추상화의 수준이 아닌 다른 관점에서 유사성을 가지고 있을 뿐이다.
현실 세계와 객체지향 세계 사이의 관계를 좀 더 정확하게 설명가능한 단어는 은유(metaphor)다.
은유는 실제로는 적용되지 않는 한 가지 개념을 이용해 다른 개념을 서술하는 대화의 한 형태로서 은유의 본질은 한 종류의 사물을 다른 종류의 사물 관점에서 이해하고 경험하는 데 있다.
이를 적용시켜보면, 비록 현실 속의 전화기는 스스로 전화를 걸 수 없다고 하더라도 우리가 익히 알고 있는 현실의 전화기라는 개념을 이용해 소프트웨어 객체를 묘사하면 그 객체가 전화를 걸 수 있다는 사실을 쉽게 이해하고 기억할 수 있게 된다.
(2) 표현적 차이와 은유적 차이
- 은유는 표현적 차이(representational gap) 또는 의미적 차이(sementic gap)라는 논점과 관련성이 깊다.
- 여기서 차이는 소프트웨어에 대해 사람들이 생각하는 모습과 실제 소프트웨어의 표현 사이의 차이를 의미.
- 은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉽게 예측할 수 있음.
즉, 이해하기 쉽고 유지보수가 용이한 소프트웨어를 만들 수 있게 됨.
이런 이유로 모든 객체지향 지침서에서는 현실 세계인 도메인에서 사용되는 이름을 객체에게 부여하라고 가이드 함.
결론
객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다. 행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다.
참고
객체지향의 사실과 오해: 역할, 책임, 협력 관점에서 본 객체지향 - 조영호 지음.
