객체지향의 사실과 오해를 읽고

객체지향 프로그래밍에 대해 많은 것을 주워들었지만, 그래서 객체지향이라는 게 무슨 말이냐? 라고 물었을 때

대답할 수 없는 스스로의 모습을 발견했습니다. 그리고 이를 해소해줄 만한 책 '객체지향의 사실과 오해'에 대해 알게 되어

 

책을 읽고 정리한 내용을 기록했습니다.

 

객체란?

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

 

객체의 상태(멤버변수, 필드)

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

 

상태 캡슐화

객체는 상태를 캡슐 안에 감쳐둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다. 이는 객체의 자율성을 높이고 협력을 단순하고 유연하게 만든다.

 

식별자

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

 

객체의 특성

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

 

객체지향의 초점은 행동이다.

객체지향의 초점은 상태가 아닌 행동이다. 행동만이 객체가 서로 협력하는 유일한 방법이 되어야한다. 객체지향의 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후, 행동을 수행할 객체를 선택하는 방식으로 수행된다. 또한, 객체에 책임을 할당하고자 할 때 기본 원칙은 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당하는 것이다.

 

의인화

현실 속 수동적인 존재가 객체로 구현될 땐 능동적으로 변한다. 즉,객체의 행동에 주체성이 생긴다. 키보드는 스스로 자판을 두드릴 수 있고, 전화기는 스스로 꺼질 수 있다.

 

추상화

어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법

• 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만듦
• 중요한 부분을 강조하기 위해 불필요한 세부사항을 제거함으로써 단순하게 만드는 것

즉, 복잡성을 이해하기 쉬운 수준으로 단순화하는 것이다.

 

객체의 협력

객체지향 설계의 전체적인 품질을 결정하는 것은 객체들 사이에 이뤄지는 협력이다.

 

객체 책임의 자율성

책임의 자율성과 추상의 정도는 문맥에 따라 다르다. 책임의 가치는 협력의 의도를 뚜렷하게 표현하면서도 자율성을 보장할 수 있어야한다. 이를 판단하는 요건 중 하나가 무엇을(What)에 집중하는 것이다. 그리고 '무엇'(메시지)을 수행하기 위해 필요한 추가적인 정보를 인자로 구성하여 전달할 수 있다.

 

메시지와 메서드

메시지는 '무엇'에 집중한다. 하지만 '어떻게'에 대한 내용은 수신자에 따라 다르게 표현할 수 있다. 우리는 이를 다형성이라고 한다.

즉, 동일한 메시지를 받더라도 객체에 따라 해당 메시지를 실행하는 메서드는 달라질 수 있다는 것이다. 그리고 메시지를 송신하는 객체는 수신하는 객체들에 대해 동일한 책임을 수행한다고 생각한다.

 

 What/Who 사이클

객체의 행위를 결정하는 것은 객체 자체의 속성이 아니다. 책임-주도 설계의 관점에서는 어떤 객체가 어떤 특성을 가지고 있다고 해서 반드시 그와 관련된 행위를 수행할 것이라고 가정하지 않는다. 반대로 행위를 먼저 식별한 후에 행위를 수행할 적절할 객체를 찾는다.

 

묻지말고 시켜라

다른 객체의 상태를 묻는 게 아니라 그저 시켜라 그 메시지를 처리하는 객체에게 처리 방법을 결정하게 하라 메세지가 어떻게 해야한다고 지시하는 것이 아니라 '무엇'을 해야 하는지를 요청하도록 해라.

 

도메인 모델

사용자들이 도메인을 바라보는 관점, 설계자가 시스템의 구조를 바라보는 관점인 동시에 소프트웨어 안에 구현된 코드의 모습, 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현하는 것

 

유스케이스

사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것으로 다음과 같은 특징들이 있다.

• 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'다.
• 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
• 유스케이스는 단순한 feature 목록과 다르다.
• 유스캐이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야한다.
• 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.