객체란 식별 가능한 개체 또는 사물입니다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있습니다. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가집니다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현됩니다.
객체의 상태
상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현합니다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성됩니다.
프로퍼티는 속성과 연관관계의 두 가지 종류로 구분됩니다.
속성(attribute)은 단순한 값입니다.
연관관계는 정적인 관계를 의미하며 링크는 연관관계의 인스턴스입니다.
객체지향 세계에서 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없습니다. 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지합니다.
객체의 행동
객체의 행동은 상태에 영향을 받습니다. 객체의 행동은 상태를 변경시킵니다.
객체는 다른 객체와 적극적으로 상호작용하며 협력하는 객체들의 공동체에 참여하기 위해 노력합니다.
객체는 다른 객체와 메시지를 통해서만 의사소통 할 수 있습니다.
행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동입니다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있습니다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 합니다.
상태를 잘 정의된 행동 집합 뒤로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만듭니다. 이것이 상태를 캡슐화해야 하는 이유입니다.
식별자
식별자란 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티입니다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교해야 합니다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 두 인스턴스를 비교할 수 있습니다.
정리
객체는 상태를 가지며 상태는 변경 가능합니다.
객체의 상태를 변경시키는 것은 객체의 행동입니다.
행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있습니다.
행동의 순서가 실행 결과에 영향을 미칩니다.
객체는 어떤 생테에 있더라도 유일하게 식별 가능합니다.
행동이 상태를 결정한다
상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼칩니다.
상태를 먼저 결정할 경우 캡슐화가 저해됩니다. 상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되버릴 확률이 높아집니다.
객체를 협력자가 아닌 고립된 섬으로 만듭니다. 객체가 필요한 이유는 애플리케이션의 문맥 내에서 다른 객체와 협력하기 위해서입니다. 불행하게도 상태를 먼저 고려하는 방식은 협력이라는 문맥에서 멀리 벗어난 채 객체를 설계하게 함으로써 자연스럽게 협력에 적합하지 못한 객체를 창조하게 됩니다.
객체의 재사용성이 저하됩니다. 객체의 재사용성은 다양한 협력에 참여할 수 있는 능력에서 나옵니다. 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기 때문에 재사용성이 저하될 수 밖에 없습니다.
책임-주도 설계(Responsibility-Driven Design, RDD)
책임-주도 설계는 협력이라는 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체를 만들 수 있게 합니다.
은유와 객체
객체지향이란 현실 세계의 모방이나 추상화가 아닌 은유입니다.
은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉽게 예측할 수 있습니다.
느낀점
객체의 협력 관계를 만드는 것이 중요한데 객체에 다른 상태들을 추가해 버린 것이 기존의 개발 방식에서 잘못 되었다는 생각을 했습니다. 상태를 기존 객체에 추가하는 것이 아닌 다른 객체를 만들어서 협력 관계를 만들었어야 했다는 생각을 했습니다.
