이 포스트는 객체지향의 사실과 오해를 읽으면서, 제 자신이 중요하다 생각하는 것을 정리하는 문서입니다. 사람마다 중요도의 기준은 다르기 때문에 간단하게 읽어주시길 바랍니다 :)
객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것.
객체지향 패러다임은 소프트웨어의 세계를 인간이 인지할 수 있는 다양한 소프트웨어 객체들이 모여 이뤄져 있다는 믿음에서 출발한다.
객체 그리고 소프트웨어의 나라.
객체의 다양한 특성을 효과적으로 설명하기 위해 객체를 상태, 행동, 식별자를 지닌 실체로 보는 것이 가장 효과적이다.
- 객체는 상태를 가지며 상태는 변경 가능하다.
- 객체를 변경시키는 것은 객체의 행동이다.
- 객체가 한 행동의 결과는 상태에 의존적이며 상태를 이용해 서술한다.
- 행동의 순서는 결과에 영향을 미친다.
- 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다.
상태
어떤 행동의 결과는 과거에 어떤 행동들이 일어났느냐에 의존한다.
상태를 이용하면 과거의 모든 행동 이력을 알 필요 없이 어떤 행동의 결과를 예측하기 쉬워진다.
객체의 상태를 구성하는 모든 특징을 통틀어 프로퍼티라고한다.
프로퍼티는 변경되지 않기에 정적이다. 하지만, 프로퍼티 값은 시간의 흐름에 따라 값이 변하기 때문에 동적이다.
객체와 객체 사이의 의미있는 연결을 링크라고한다.
객체와 객체 사이에서는 링크를 통해서만 메시지를 전달 할 수 있다.
프로퍼티는 객체를 구성하는 단순한 값인 속성(attribute)과 객체와 객체 사이의 연결(참조)인 링크라는 두 가지 종류의 조합을 표현 할 수 있다.
상태
- 프로퍼티
- 단순 속성
- 링크
- 프로퍼티 값
행동
객체의 상태는 저절로 변경되지 않음. 객체의 자발적인 행동만이 객체의 상태를 변경시킬 수 있음.
객체의 행동이 상태를 변화시킨다는 것은 객체의 행동이 부수 효과(side effect)를 야기한다는 것.
- 객체의 행동은 상태에 영향을 받는다.
- 객체의 행동은 상태를 변경시킨다.
협력과 행동
- 객체는 다른 객체와 적극적으로 상호작용하며 '협력하는 객체들의 공동체'가 되기 위해 노력한다.
- 객체가 다른 객체와 협력하는 유일한 방법은 다른 객체에게 요청을 보내는 것이다.
- 객체는 다른 객체와 메시지를 통해서만 의사소통할 수 있다.
- 객체는 협력에 참여하는 과정에서 다른 객체의 상태 변화를 유발할 수 있다.
- 행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이여야한다.
상태 캡슐화
메시지 송신자는 메시지 수신자의 상태 변경에 대해서는 전혀 알지 못한다.
객체는 상태를 캡슐안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체가 접근 할 수 있는 유일한 방법 역시 행동이다.
상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 결과적으로 객체의 자율성을 높인다. 이렇게 자율성이 높아지면 협력하는 객체들의 협력은 유연하고 간결해진다.
캡슐화의 이유
- 상태를 잘 정의 된 행동 뒤로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만들어준다.
식별자
객체가 식별 가능하다는 것은 객체를 서로 구별할 수 있는 특정한 프로퍼티가 객체안에 존재한다는 것을 의미한다.
이 프로퍼티가 식별자이다. 모든 객체는 식별자를 가지며 이를 이용해 서로 구별 할 수 있게된다.
값(value)은 숫자, 문자열, 날짜, 시간, 금액 등과 같이 변하지 않는 양을 모델링한다. 흔히 값의 상태는 변하지 않기 때문에 불변 상태(immutable state)를 가진다고 말한다. 값의 경우 두 인스턴스의 상태가 같다면 두 인스턴스를 같다고 표현한다.
상태를 이용해 두 값이 같은지 판단할 수 있는 성질 → 동등성(equality)
객체는 시간에 따라 변경되는 상태를 포함하며, 행동을 통해 상태를 변경한다. 따라서 객체는 가변 상태(mutable state)를 가진다고 말한다. 타입이 같은 두 객체의 상태가 완전히 똑같더라도 두 객체는 독립적인 별개의 객체로 다루어야한다. 객체는 두 객체를 동일하거나 다르다고 판단할 수 있는 프로퍼티를 가진다. 두 객체의 상태가 다르더라도 식별자가 같으면 같은 객체로 판단할 수 있다.
식별자를 기반으로 객체가 같은지 판단할 수 있는 성질 → 동일성(identical)
식별자
- 어떤 객체를 다른 객체와 구분하는 데 사용하는 프로퍼티
- 값은 식별자를 가지지않기 때문에 동등성 검사를, 객체는 식별자를 이용한 동일성 검사를 진행해야 인스턴스를 비교할 수 있다.
지금까지 살펴본 객체의 특성
- 객체는 상태를 가지며 상태는 변경 가능하다.
- 객체를 변경시키는 것은 객체의 행동이다.
- 객체가 한 행동의 결과는 상태에 의존적이며 상태를 이용해 서술한다.
- 행동의 순서는 결과에 영향을 미친다.
- 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다.
기계로서의 객체
객체지향의 세계를 창조하는 개발자들의 주된 업무는 객체의 상태를 조회하고 객체 상태를 변경하는 것이다.
객체의 상태를 조회하는 작업을 쿼리(query)라고하고 객체의 상태를 변경하는 작업을 명령(command)이라고한다.
기계의 부품은 단단한 금속외피에 감춰져있기 때문에, 사람은 기계의 외부에 부탁된 버튼을 이용하여 상호작용 할 수 있다. 버튼을 누르면 기계의 상태를 변경 할 수 있고 조회할 수 있다.
기계는 사용자가 명령 버튼을 눌러야 상태를 변경할 수 있고, 조회 버튼을 눌러야 상태를 조회할 수 있다. 어떤 사용자도 기계 내부를 열어서 상태에 직접 접근하려하지 않는다.
똑같이 생긴 기계가 두 개 있더라도 사람은 두 기계를 같은 기계라고 인식하지않는다. 서로 구분된 별개의 객체로 인식할 뿐이다.
서로 다른 연결된 기계가 협력하려면 연결되어 있는 기계가 다른 기계에게 요청을 하는 방법밖에 없다.
→ 객체를 기계로서 바라보는 관점은 상태, 행동, 식별자에 대한 시각적인 이미지를 제공하고 캡슐화와 메시지를 통한 협력 관계를 매우 효과적으로 설명한다.
행동이 상태를 결정한다.
대부분은 상태를 먼저 결정하고 행동을 나중에 결정하는 방법을 사용하여 설계를한다.
하지만 위와 같은 방법은 설계에 나쁜 영향을 준다.
- 캡슐화가 저해된다. 상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되버릴 확률이 높아진다.
- 객체를 협력자가 아닌 고립된 섬으로 만든다. 상태를 먼저 고려하는 방식은 협력이라는 문맥에서 멀리 벗어난 채 객체를 설계함으로써 자연스럽게 협력에 적합하지 못한 객체를 창조하게 된다.
- 객체의 재사용성이 저하된다. 객체의 재사용성은 다양한 협렵에 참여할 수 있는 능력에서 나온다. 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기 때문에 재사용성이 저하될 수 밖에 없다.
설계자로서 우리는 협력의 문맥에 맞는 행동을하는 객체를 발견하거나 창조해야한다.
객체지향 설계는 협력을 생각하고 협력에 필요한 행동을 생각한 뒤 행동을 수행할 객체를 선택하는 방식이여야한다. 그 후에야 상태가 결정된다.
책임 주도 설계(Responsibility-Driven Design)는 협력이라는 문맥 안에서 객체의 행동을 생각하도록 도움으로써 응집도 높고 재사용 가능한 객체를 만들 수 있게 한다.
은유와 객체
객체지향은 오롯이 현실을 모방하고 추상화하는 것이 아니다.
의인화
현실속에서 수동적인 존재가 소프트웨어속의 객체가 되면 능동적으로 변한다.
소프트웨어 속에서 우리가 객체를 창조할 때는 현실 세계의 객체를 모방하지않고, 전혀 다른 특징을 부여하게 된다.
이렇게 현실의 객체보다 더 많은 일을 할 수 있는 소프트웨어의 특징을 의인화(anthropomorphism)라고한다.
은유
현실 속의 객체의 의미 일부가 소프트웨어 객체로 전달되기 때문에 프로그램 내의 객체는 현실 속의 객체에 대한 은유다.
은유를 효과적으로 사용할 경우 현실의 객체와 소프트웨어 객체 사이의 표현적 차이를 줄일 수 있으며, 이해하기 쉽고 유지보수가 용이한 소프트웨어를 만들 수 있다.
→ 현실 세계의 도메인에서 사용되는 이름을 객체에게 부여해야하는 이유
- 우리의 목적은 현실을 모방하는 것이 아니다. 단지 이상한 나라를 창조하기만하면 된다.
