객체와 상태
객체
객체란 식별 가능한 개체 또는 사물이다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별 가능한
식별자
, 독립적인 행동
, 변경 가능한 상태
를 가진다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현된다.상태
상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현함. 객체의 상태는 객체에 존재하는
정적인 프로퍼티
와 동적인 프로퍼티
값으로 구성됨. 객체의 프로퍼티는 단순한 값
과 다른 객체를 참조하는 링크
로 구분할 수 있다.- 모든 객체의
상태
는 단순한값
과객체의 조합
으로 표현할 수 있음
- 객체와 객체 사이의 의미 있는 연결을
링크(link)
- 링크는 객체가 다른 객체를 참조할 수 있다는 것을 의미. 이를 통해 요청을 보내고 받음
- 객체의
상태
를 구성하는 모든 특징을 통틀어 객체의프로퍼티
라고 함 프로퍼티
=단순한 값인 속성
+다른 개체를 가리키는 링크
협력과 행동
행동
행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.
- 객체가 다른 객체와 협력하는 유일한 방법은 다른 객체에게 요청을 보내는 것이다.
- 요청을 수신한 객체는 요청을 처리하기 위해 적절한 방법에 따라 행동한다.
- 따라서 객체의 행동은 객체가 협력에 참여할 수 있는 유일한 방법이다
상태 캡슐화
- 객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재
- 메시지를 앨리스에게 전송
drinkBeverage()
하는 객체이건 음료에게 메시지를 전송drunken(quality)
하는 앨리스 객체이선 메시지 송신자는 메시지 수신자의 상태 변경에 대해서는 전혀 알지 못함 ⇒ 캡슐화
- 객체는 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다.
- 상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 결과적으로 객체의 자율성을 높인다. 자율적인 객체는 스스로 판단하고 스스로 결정하기 때문에 객체의 자율성이 높아질수록 객체의 지능도 높아짐. 협력에 참여하는 객체들의 지능이 높아질수록 협력은 유연하고 간결해진다.
식별자
식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교해야 한다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교할 수 있다.
- 값(value)은 숫자, 문자열, 날짜, 시간, 금액 등과 같이 변하지 않는 양을 모델링함
- 흔히 값의 상태는 변하지 않기 때문에
불변 상태
(immutable state)를 가짐 (값객체. VO) - 상태를 이용해 두 값이 같은지 판단할 수 있는 성질 ⇒
동등성
(equality)
- 객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경
- 따라서 객체는
가변 상태
(mutable state)를 가짐 - 두 객체의 상태가 다르더라도 식별자가 같다면 두 객체를 같은 객체로 판단할 수 있음
- 이처럼 식별자를 기반으로 객체가 같은지를 판단할 수 있는 성질 ⇒
동일성
(identical)
기계로서의 객체 — 버트란드 마이어
- 일반적으로 객체의 상태를 조회하는 작업을 쿼리(query) — Getter
- 객체의 상태를 변경하는 작업을 명령(command)이라고 함
** 행동이 상태를 결정한다
- 객체지향에 갓 입문한 사람들이 가장 쉽게 빠지는 함정은 상태를 중심으로 객체를 바라보는 것이다. 초보자들은 먼저 객체에 필요한 상태가 무엇인지를 결정하고 그 상태에 필요한 행동을 결정한다.
- 안타깝게도 상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.
- 상태를 먼저 결정할 경우 캡슐화가 저해된다. 상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되버릴 확률이 높아짐
- 객체를 협력자가 아닌 고립된 섬으로 만든다. 객체가 필요한 이유는 애플리케이션의 문맥 내에서 다른 객체와 협력하기 위해서다. 상태를 먼저 고려하는 방식은 협력이라는 문맥에서 멀리 벗어난 채 객체를 설계하게 함으로써 자연스럽게 협력에 적합하지 못한 객체를 창조하게 된다.
- 객체의 재사용성이 저하된다. 객체의 재사용성은 다양한 협력에 참여할 수 있는 능력에서 나온다. 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기 때문에 재사용성이 저하될 수 밖에 없다.
- 객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행됨
- 행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정됨
- 협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미하고 따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다 ⇒ 책임-주도 설계
은유와 객체
- 객체지향 세계는 현실세계의 단순한 모방이 아니다. 소프트웨어 안에 구성된 상품 객체는 실제 세계의 상품과는 전혀 다른 양상을 띤다
의인화
- 현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다는 것
객체는 무생물이거나 심지어는 실세계의 개념적인 개체로 모델링될 수도 있지만 그것들은 마치 우리가 현실 세계에서 에이전트로 행동하는 것처럼 시스템 안에서 에이전트처럼 행동한다. 객체가 현실 세계의 대상보다 더 많이 안다는 것이 모순처럼 보일 수도 있다. 결국, 인간이라는 에이전트 없이 현실의 전화는 서로에게 전화를 걸지 않으며 색은 스스로 칠하지 않는다. 일상적인 체계에서는 어떤 사건이 일어나기 위해 반드시 인간 에이전트가 필요한 반면 객체들은 그들 자신의 체계 안에서 [능동적이고 자율적인] 에이전트다.
의인화의 관점에서 소프트웨어를 생물로 생각하자. 모든 생물처럼 소프트웨어는 태어나고, 삶을 영위하고, 그리고 죽는다[Wrifs-Brock 1990]