[객체지향의 사실과 오해] 2. 이상한 나라의 객체 - 개발 도서 정독하기

객체지향 패러다임은 지식을 추상화하고 추상화한 지식을 객체 안에 캡슐화함으로써 실세계 문제에 내재된 복잡성을 관리하려고 한다. 객체를 발견하고 창조하는 것은 지식과 행동을 구조화하는 문제다.
Rebecca Wirfs-Brock

 

 

객체지향과 인지 능력

인간은 본능적으로 세상을 독립적이고 식별 가능한 객체의 집합으로 바라본다. 많은 사람들이 객체지향을 직관적이고 이해하기 쉬운 패러다임이라고 말하는 이유는 객체지향이 세상을 자율적이고 독립적인 객체들로 분해할 수 있는 인간의 기본적인 인지 능력에 기반을 두고 있기 때문이다.

 

인간이 직접적으로 지각할 수 있는 대부분의 객체는 물리적인 경계를 지닌 구체적인 사물이다. 그러나 인간의 인지 능력은 물리적인 한계를 넘어 개념적으로 경계 지을 수 있는 추상적인 사물까지도 객체로 인식할 수 있게 한다.

오늘의 주문 내역과 어제의 주문 내역을 구분한다거나 출금 계좌에서 동일한 입금 계좌로 동일한 금액을 두 번 이체하더라도 각 계좌 이체는 명확하게 구분 가능하다. 주문과 계좌 이체는 물리적인 실체는 존재하지 않더라도 인간이 쉽게 구분하고 하나의 단위로 인지할 수 있는 개념적인 객체의 일종이다.

 

객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것이다.

객체지향 패러다임은 인간이 인지할 수 있는 다양한 소프트웨어 객체들이 모여 이뤄져 있다는 믿음에서 출발한다. 현실 세계와 소프트웨어 세계의 유사성은 여기까지다.

객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아닌 현실 세계를 기반으로 새로운 세계를 창조하는 것이다. 따라서 소프트웨어 세계에서 살아가는 객체는 현실 세계에 존재하는 객체와는 전혀 다른 모습을 보이는 것이 일반적이다.

 

 

객체, 그리고 소프트웨어 나라

하나의 개별적인 실체로 식별 가능한 물리적인 또는 개념적인 사물은 어떤 것이라도 객체가 될 수 있다. 객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를 상태(State), 행동(Behavior), 식별자(Identity)를 지닌 실체로 보는 것이 가장 효과적이다.

 

이 책에서는 객체를 다음과 같이 정의하기로 한다.

객체란 식별 가능한 개체 또는 사물이다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현된다.

 

상태

왜 상태가 필요한가

객체가 주변 환경과의 상호작용에 어떻게 반응하는가는 그 시점까지 객체에 어떤 일이 발생했느냐에 좌우된다.

• 비행기에 탑승하려면 항공권을 발권한 상태여야 한다.
• 자판기의 음료를 뽑기 위해서는 금액이 투입된 상태여야 한다.
• 엘리베이터가 움직이기 위해서는 목적지에 해당하는 층의 버튼을 누른 상태여야 한다.
• 운전을 하기 위해서는 시동을 건 상태여야 한다.

 

상태를 이용하면 과거의 모든 행동 이력을 설명하지 않고도 행동의 결과를 쉽게 예측하고 설명할 수 있다. 과거에 얽매이지 않고 현재를 기반으로 객체의 행동 방식을 이해할 수 있다.

상태는 근본적으로 세상의 복잡성을 완화하고 인지 과부하를 줄일 수 있는 중요한 개념이다.

 

상태와 프로퍼티

숫자, 문자열, 양, 속도, 시간, 날짜, 참/거짓과 같은 단순한 값들은 객체가 아니다. 단순한 값들은 그 자체로 독립적인 의미를 가지기보다는 다른 객체의 특성을 표현하는 데 사용된다. 다시 말해 다른 객체의 상태를 표현하기 위해 사용된다.

 

때로는 단순한 값이 아니라 객체를 사용해 다른 객체의 상태를 표현해야 할 때가 있다. 예를 들어 음료라는 객체와 사람이라는 객체를 통해 ‘음료를 들고 있는 사람’을 표현하는 것이다. 사람이 음료를 들고 있는지 여부는 사람 객체가 음료 객체와 연결돼 있는지 여부로 표현할 수 있다.

이때 사람과 음료는 객체다. 그러나 사람의 키와 위치, 음료의 양은 객체가 아닌 단순한 값이다. 사람의 상태는 키와 위치라는 단순한 값과 음료라는 객체의 조합으로 표현할 수 있다.

 

결론적으로 모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다. 이때 객체의 상태를 구성하는 모든 특징을 통틀어 객체의 프로퍼티(Property)라고 한다. 사람의 경우 키와 위치, 음료가 프로퍼티가 된다. 일반적으로 프로퍼티는 변경되지 않고 고정되기 때문에 정적이다. 반면 프로퍼티 값(Property value)은 시간이 흐름에 따라 변경되기 때문에 동적이다.

 

다른 시점의 사람을 표현한 것이다. 이 시점에 사람의 키는 40, 위치는 정원으로 바뀌었다. 또한 사람과 음료 사이의 선이 없어진 것으로 보아 더는 음료를 가지고 있지 않는다. 사람은 음료에 관해 알고 있었지만 이때부터는 음료에 관해 알지 못하는 상태로 변경되었음을 의미한다.

 

이처럼 객체와 객체 사이의 의미 있는 연결을 링크(link)라고 한다. 객체와 객체 사이에는 링크가 존재해야만 요청을 보내고 받을 수 있다. 링크는 객체가 다른 객체를 참조할 수 있다는 것을 의미하며, 일반적으로 한 객체가 다른 객체의 식별자를 알고 있는 것으로 표현된다.

 

객체 간의 선으로 표현되는 링크와 달리 객체를 구성하는 단순한 값은 속성(Attribute)이라고 한다. 사람의 키와 위치를 단순한 값으로 표현되기 때문에 속성이다. 객체의 프로퍼티는 단순한 값인 속성과 다른 객체를 가리키는 링크라는 두 가지 종류의 조합으로 표현할 수 있다.

 

객체의 상태

객체지향의 사실과 오해에서는 객체의 상태를 다음과 같이 정의한다.

상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분할 수 있다.

 

객체는 자율적인 존재라는 점을 명심해야 한다. 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 객체 스스로 자신의 상태를 책임져야 한다.

외부의 객체가 직접적으로 객체의 상태를 주무를 수 없다면 간접적으로 상태를 변경하거나 조회할 수 있는 방법이 필요하다. 이때 필요한 것이 행동이다.

 

행동

행동은 다른 객체로 하여금 간접적으로 객체의 상태를 변경하는 것을 가능하게 한다. 객체지향의 기본 사상은 상태와 상태를 조작하기 위한 행동을 하나의 단위로 묶는 것이라는 점을 기억하라.

객체가 취하는 행동은 객체 자신의 상태를 변경시킨다. 객체의 행동에 의해 객체의 상태가 변경된다는 것은 행동이 부수 효과(side effect)를 초래한다는 것을 의미한다.

 

객체의 행동은 객체의 상태를 변경시키지만 행동의 결과는 객체의 상태에 의존적이다.

• 객체의 행동은 상태에 영향을 받는다.
• 객체의 행동은 상태를 변경시킨다.

 

상태라는 개념을 이용해 행동을 다음의 두 가지 관점에서 서술할 수 있음을 의미한다.

• 상호작용이 현재의 상태에 어떤 방식으로 의존하는가
• 상호작용이 어떻게 현재의 상태를 변경시키는가

 

 

협력과 행동

객체는 자신에게 주어진 책임을 완수하기 위해 다른 객체를 이용하고 다른 객체에게 서비스를 제공한다. 객체는 다른 객체와 적극적으로 상호작용하며 ‘협력하는 객체들의 공동체’에 참여하기 위해 노력한다.

• 객체가 다른 객체와 협력하는 유일한 방법은 다른 객체에게 요청을 보내는 것이다.
• 객체가 다른 객체와 메시지를 통해서만 의사소통할 수 있다.
• 객체는 협력에 참여하는 과정에서 자기 자신의 상태뿐만 아니라 다른 객체의 상태 변경을 유발할 수 있다.

 

이 책에서는 행동을 다음과 같이 정의한다.

행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.

 

 

상태 캡슐화

현실 세계의 객체와 객체지향 세계의 객체 사이에는 중요한 차이점이 있다. 객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재다.

현실세계의 사람과 음료 객체라면 사람은 스스로 음료를 마시는 능동적인 존재지만 음료 스스로는 아무것도 할 수 없다. 반면에 객체지향의 세계에서는 사람이 음료에게 자신이 음료를 마셨다는 메시지를 전달할 수 있을 뿐이다. 음료의 양을 줄이는 것은 메시지를 전달받은 음료 스스로의 몫이다.

 

사람이 음료를 마시는 과정에서 이뤄지는 사람과 음료 사이의 협력 관계를 다음과 같이 표현할 수 있다.

사람과 음료에게 전송되는 메시지 이름에 주목하라.

• 사람에게 전달되는 메시지는 drinkBeverage()이고 음료에게 전달되는 메시지는 drunken(quantity)다.
• 메시지를 사람에게 전송하는 객체이건 음료에게 메시지를 전송하는 사람 객체이건 메시지 송신자는 메시지 수신자의 상태 변경에 대해서는 전혀 알지 못한다.

이것이 캡슐화(Encapsulation)가 의미하는 것이다.

객체는 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다. 객체에게 메시지를 전달하는 외부의 객체는 메시지를 수신하는 객체의 상태가 변경된다는 사실조차 알지 못한다.

 

결론적으로 상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만든다.

 

식별자

객체란 인간의 인지 능력을 이용해 식별 가능한 경계를 가진 모든 사물을 의미하며, 객체가 식별 가능하다는 것은 객체를 서로 구별할 수 있는 특정한 프로퍼티가 객체 안에 존재한다는 것을 의미한다.

이 프로퍼티를 식별자라고 한다. 모든 객체는 식별자를 가지며 식별자를 이용해 객체를 구별할 수 있다.

 

객체가 가지는 프로퍼티의 타입은 객체나 단순한 값 중 하나가 될 수 있다. 값과 객체의 가장 큰 차이점은 값은 식별자를 가지지 않지만 객체는 식별자를 가진다는 점이다. 시스템을 설계할 때는 이런 단순한 값과 객체의 차이점을 명확하게 구분하고 명시적으로 표현하는 것이 매우 중요하다.

 

값(Value)

값은 숫자, 문자열, 날짜, 시간, 금액 등과 같이 변하지 않는 양을 모델링한다. 흔히 값의 상태는 변하지 않기 때문에 불변 상태(Immutable state)를 가진다고 말한다.

값이 같은지 여부는 상태가 같은지를 이용해 판단한다. 값의 상태가 같으면 두 인스턴스는 동일한 것으로 판단하고 상태가 다르면 두 인스턴스는 다른 것으로 판단한다. 이처럼 상태를 이용해 두 값이 같은지 판단할 수 있는 성질을 동등성(Equality)이라고 한다.

 

객체(Object)

객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다. 따라서 객체는 가변 상태(Mutable state)를 가진다고 말한다. 두 객체의 상태가 완전히 똑같더라도 두 객체는 독립적인 별개의 객체로 다뤄야 한다.

• 이름과 키, 나이가 모두 동일한 두 사람이 함께 있다고 해도 이 둘은 같은 사람이 아니다.
• 어린 시절의 나와 현재의 나는 키와 나이가 다르지만 동일한 인물이다.

객체는 상태와 무관하게 두 객체를 동일하거나 다르다고 판단할 수 있는 프로퍼티를 가진다. 두 객체의 상태가 다르더라도 식별자가 같다면 두 객체를 같은 객체로 판단할 수 있다. 이처럼 식별자를 기반으로 객체가 같은지를 판단할 수 있는 성질을 동일성(identical)이라고 한다.

 

식별자(identifier)

식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성(Equality) 검사를 통해 두 인스턴스를 비교해야 한다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성(identical) 검사를 통해 두 인스턴스를 비교할 수 있다.

 

대부분의 객체지향 프로그래밍 언어에서 값과 객체 모두 클래스에 이용해 구현된다. 객체지향 프로그래밍 언어를 이용하면 숫자는 Integer라는 클래스로, 사람은 Person이라는 클래스로 정의할 수밖에 없다. 따라서 숫자는 Integer 클래스로부터 생성된 객체이며, 사람은 Person 클래스로부터 생성된 객체다. 객체지향 언어의 관점에서 값과 객체 모두 클래스로부터 생성된 객체이기 때문에 문맥에 따라 그 의미가 혼란스러워질 수 있다.

 

이런 오해의 소지를 줄이기 위해 객체와 값을 지칭하는 별도의 용어를 사용하기도 한다. 참조 객체(Reference object), 또는 엔티티(Entity)는 식별자를 지닌 전통적인 의미의 객체를 가리키는 용어다. 값 객체(Value object, VO)는 식별자를 가지지 않는 값을 가리키는 용어다. 이 책에서 특별한 언급이 없는 한 객체라는 용어는 식별자를 가지는 참조 객체나 엔티티를 가리킨다.

 

객체의 특성 요약

• 객체는 상태를 가지며 상태는 변경 가능하다.
• 객체의 상태를 변경시키는 것은 객체의 행동이다.
  • 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있다.
  • 행동의 순서가 실행 결과에 영향을 미친다.
• 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다.

 

 

기계로서의 객체

객체지향 프로그래밍 개발자들의 주된 업무는 객체의 상태를 조회하고 객체의 상태를 변경하는 것이다. 객체의 상태를 조회하는 작업을 쿼리(Query)라고 하고 객체의 상태를 변경하는 작업을 명령(Command)이라고 한다. 객체가 외부에 제공하는 행동의 대부분은 쿼리와 명령으로 구성된다.

 

버트란드 마이어는 ‘Object-Oriented Software Construction’에서 객체를 기계에 비유해서 설명하고 있다.

• 기계의 부품은 단단한 금속 외피에 감춰져 있기 때문에 기계를 분해하지 않는 한 기계의 내부를 직접 볼 수는 없다.(캡슐화)
• 사람은 기계의 외부에 부착된 버튼을 이용해서 기계와 상호작용할 수 있다.(메시지)
• 어떤 사용자도 직접 기계를 열어 내부의 상태에 직접 접근하려고 하지 않는다.

객체를 기계로서 바라보는 관점은 상태, 행동, 식별자에 대한 시각적인 이미지를 제공하고 캡슐화와 메시지를 통한 협력 관계를 매우 효과적으로 설명한다.

 

 

행동이 상태를 결정한다

객체지향에 입문한 사람들이 가장 쉽게 빠지는 함정은 상태를 중심으로 객체를 바라보는 것이다. 상태를 먼저 결정하고 행동을 나중에 결정한다는 의미다. 이 방법은 설계에 나쁜 영향을 끼친다.

1. 상태를 먼저 결정할 경우 캡슐화가 저해된다. 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출 돼버릴 확률이 높아진다.
2. 객체를 협력자가 아닌 고립된 섬으로 만든다. 객체가 필요한 이유는 애플리케이션 문맥 내에서 다른 객체와의 협력하기 위해서다. 상태를 먼저 고려하는 방식은 협력으로부터 멀어진다.
3. 객체의 재사용성이 저하된다. 객체의 재사용성은 다양한 협력에 참여할 수 있는 능력에서 나온다. 상태에 초점을 맞추면 다양한 협력에 참여하기 어려워 재사용성이 저하된다.

 

협력에 참여하는 훌륭한 객체는 상태가 아닌 행동에 초점을 맞춘다. 객체의 행동은 객체가 협력에 참여하는 유일한 방법이기 때문에 객체가 적합한지를 결정하는 것은 객체의 상태가 아닌 행동이다. 설계자로서 우리는 협력의 문맥에 맞는 적절한 행동을 수행하는 객체를 발견하거나 창조해야 한다.

 

객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다. 행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다.

 

협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다. 따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다. 앞으로 이 책에서 살펴볼 책임-주도 설계(Responsibility-Driven Design, RDD)는 협력이라는 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체를 만들 수 있게 한다.

 

이 장을 통틀어 가장 중요하고 반드시 기억해야 하는 부분은 “행동이 상태를 결정한다”는 것이다.

 

 

은유와 객체

객체지향을 현실 세계의 모방이라고 보는 관점은 객체지향 분석/설계란 현실 세계에 존재하는 다양한 객체를 모방한 후 필요한 부분만 취해 소프트웨어 객체로 구현하는 과정이라고 설명한다.

이를 현실 세계의 추상화라고도 하는데, 추상화(Abstraction)란 실제의 사물에서 자신이 원하는 특성만 취하고 필요 없는 부분을 추려 핵심만 표현하는 행위를 말한다.

 

안타깝게도 객체지향 세계는 현실 세계의 단순한 모방이 아니다. 소프트웨어 안에 구현된 상품 객체는 실제 세계의 상품과는 전혀 다른 양상을 띤다. 소프트웨어의 상품은 실제 세계의 상품이 하지 못하는 가격 계산과 같은 행동을 스스로 수행할 수 있다.

이는 소프트웨어 상품이 실제 세계의 상품을 단순화하거나 추상화한 것이 아니라 특성이 전혀 다른 어떤 것임을 의미한다.

 

모방과 추상화라는 개념만으로는 현실 객체와 소프트웨어 객체 사이의 관계를 깔끔하게 설명하지 못한다.

 

의인화

현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다는 것이다.

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

 

소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실의 모습을 조금 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다. 또한 객체지향의 세계는 현실의 추상화가 아니다. 오히려 객체지향 새계의 거리는 현실속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.

 

은유

현실 세계와 객체지향 세계 사이의 관계를 좀 더 정확하게 설명할 수 있는 단어는 은유(metaphor)다. 은유란 실제로는 적용되지 않는 한 가지 개념을 이용해 다른 개념을 서술하는 대화의 형태다. 은유의 본질은 한 종류의 사물을 다른 종류의 사물 관점에서 이해하고 경험하는 데 있다.

 

은유는 표현적 차이(Representational gap) 또는 의미적 차이(Semantic gap)라는 논점과 관령성이 깊다. 여기서 차이란 소프트웨어에 대해 사람들이 생각하는 모습과 실제 소프트웨어의 표현 사이의 차이를 의미한다.

 

은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉽게 예측할 수 있다. 이는 모든 객체지향 지침서에서 현실 세계인 도메인에서 사용되는 이름을 객체에게 부여하라고 가이드하는 이유다.

 

이상한 나라를 창조하라

객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다. 객체의 특성을 상기시킬 수 있다면 현실 속의 객체의 이름을 이용해 객체를 묘사하라. 그렇지 않다면 깔끔하게 현실을 무시하고 자유롭게 자신만의 새로운 세계를 창조하기를 바란다.

 

https://link.coupang.com/a/ZgFOz

객체지향의 사실과 오해 : 역할 책임 협력 관점에서 본 객체지향

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."