협력하는 객체들의 공동체
객체지향의 목표는 실세계를 모방하는 것이 아닌 새로운 세계를 창조하는 것.
객체들은 협력을 위해 특정한 역할을 맡고 역할에 적합한 책임을 수행한다.
- 여러 객체가 동일한 역할을 수행할 수 있다.
- 역할은 대체 가능성을 의미한다.
- 각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다.
- 하나의 객체가 동시에 여러 역할을 수행할 수 있다.
어플리케이션의 기능은 더 작은 책임으로 분할되고 책임은 적절한 역할을 수행할 수 있는 객체에 의해 수행된다.
시스템은 역할과 책임을 수행하는 객체로 분할되어 있으며 시스템의 기능은 객체 간의 연쇄적인 요청과 응답의 흐름으로 구성된 협력으로 구현됨.
적절한 객체에게 적절한 책임을 할당.
역할은 관련성 높은 책임의 집합.
객체는 충분히 협력적이며 자율적이어야 함.
객체는 필요한 행동과 상태를 함께 지니고 있다. 객체의 사적인 부분은 객체 스스로 관리하고 외부에서 일체 간섭할 수 없도록 차단해야하며 외부에서 접근하려면 허락된 수단을 통해서만 의사소통 할 수 있다.
외부에서 객체에 접근하기 위해 요청을 보내는 것을 메세지라고 한다. 객체 내부에서 메세지를 처리하는 방법을 메소드라고 한다.
외부의 요청이 무엇인지를 표현하는 메세지와 요청을 처리하기 위한 구체적인 방법인 메소드를 분리하는 것이 중요
그래서 객체지향이란?
- 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법.
- 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미
- 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력. 각 객체는 협력 내에서 정해진 역할 수행. 역할은 관련된 책임의 집합.
- 객체는 다른 객체와 협력하기 위해 메세지를 전송하고, 메세지를 수신한 객체는 메세지를 처리하는 데 적합한 메소드를 자율적으로 선택.
객체
식별 가능한 개체 또는 사물. 구체적인 개념과 추상적인 개념 모두 포함. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가짐. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현됨.
객체의 상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현. 객체의 상태는 객체에 존재하는 정적이 프로퍼티와 동적인 프로퍼티 값으로 구성. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분.
객체의 행동은 객체의 상태를 변경시키지만 행동의 결과는 객체 상태에 의존적
객체가 다른 객체와 협력하는 유일한 방법은 다른 객체에 메세지를 보내는 것.
단순 값과 객체의 차이점은 값은 식별자를 가지지 않지만, 객체는 식별자를 가진다는 것.
즉 객체란?
- 객체는 상태를 가지며 상태는 변경 가능
- 객체의 상태를 변화시키는 것은 객체의 행동. 행동의 결과는 상태에 의존적이며, 상태를 이용해 서술 가능. 또한 행동의 순서가 실행 결과에 영향 미침
- 객체는 식별자를 가지고 있으므로 어떤 상태에서도 유일하게 식별 가능
객체 지향의 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동의 수행할 객체를 선택
추상화
어떤 양상, 세부 사항, 구조를 좀 더 명화하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법.
구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화
중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것
추상화의 목적은 복잡성을 이해하기 쉬운 수준으로 단순화하는 것
타입
메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터. 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정.
객체의 타입은
- 어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동. 동일한 행동을 수행하는 두 객체는 동일한 타입으로 분류될 수 있다.
- 객체의 내부적인 표현은 외부로부터 철저하게 감춰짐. 객체 내부 상태는 어떤 방식으로 표현하더라도 무방.
즉 객체의 타입은 객체의 행동에 따라 결정. 객체를 결정하는 것은 행동이다.
객체를 분류하기 위한 기준 = 타입
타입을 나누는 기준 = 객체의 행동
클래스 != 타입
협력
협력을 고려하지 않고 객체의 상채와 행동부터 고민하면 안됨.
협력이 자리 잡으면 객체의 행동이 드러나고 객체의 상태가 결정된다.
협력의 본질은 요청과 응답. 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의.
어떤 대상에 대한 요청은 그 대상이 해당 요청을 처리할 책임이 있음을 암시.
책임은 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장. 일반적으로 외부에 제공해 줄 수 있는 정보와 외부에 제공해 줄 수 있는 서비스의 목록 -> 공용 인터페이스 구성
객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고 어떤 객체로부터 메세지를 수신할 것인지를 결정하는 것으로부터 시작
역할은 어떤 객체가 수행하는 책임의 집합. 동일한 역할을 수행할 수 있다는 것은 해당 객체들이 협력 내에서 동일한 책임의 집합을 수행할 수 있다는 것
올바른 객체를 설계하기 위해서는 먼저 견고하고 깔끔한 협력을 설계해야한다. 즉, 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 결정해야한다. 이렇게 결정된 요청과 응답의 흐름은 객체가 협력에 참여하기 위한 책임이 된다. 책임은 객체가 외부에 제공해야 할 행동이 되며 그 후에 데이터를 고민해야한다.
책임
책임은 수행 방법을 제한할 정도로 너무 구체적이여도 안되고, 협력의 의도를 명확하게 표현하지 못할 정도로 추상적이어도 안된다.
책임은 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이어야함
어떻게(how)가 아닌 무엇(what)을 해야하는지에 대한 설명
클래스에 중점 두지 말기
클래스는 단지 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위한 추상화 도구. 중요한 것은 클래스가 아니라 객체. 클래스를 정의하기 전에 객체들의 속성과 행위를 식별하는 것이 먼저.
독립된 객체의 상태와 행위에 대해 고민하지 말고 객체가 다른 객체에게 제공해야 하는 메세지에 대해 고민. 메세지가 객체를 선택한다.
1) 메세지를 먼저 결정
2) 메세지를 수신할 후보를 선택
객체의 인터페이스
객체가 다른 객체와 상호작용할 수 있는 방법은 메세지 전송. 객체의 인터페이스는 객체가 수신할 수 있는 메세지의 목록.
- 너무 구체적인 인터페이스보다 추상적인 인터페이스가 좋다.
- 외부에서 사용할 필요가 없는 인터페이스는 노출하지 마라.
- 인터페이스와 구현은 분리되어야함.
좋은 객체는 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체. 객체 외부에 노출되는 인터페이스와 객체 내부에 숨겨지는 구현을 명확히 구분해야 함.
구조
기능은 자주 변경된다. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성해야 한다.
구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다. 객체의 구조에 집중하고 기능이 구조를 따르게 만든다.
안정적인 객체 구조는 변경을 수용할 수 있는 유연한 소프트웨어를 만들 수 있는 기반을 제공한다.
구조는 도메인 모델로 표현할 수 있다. 도메인 모델은 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태이다.
객체 설계는 요구사항들을 식별하고 도메인 모델을 생성한 후, 클래스에 메소드를 추가하고 요구사항을 충족시키기 위해 객체들 간의 메세지 전송을 정의하는 식으로 설계된다.
안정적인 도메인 모델을 기반으로 시스템 기능을 구현하면 시스템의 기능이 변경되더라도 비즈니스의 핵심 정책이나 규칙이 변경되지 않는 한 전체적인 구조가 한 번에 흔들리지는 않는다.
설계부터 구현까지의 과정
1) 시스템을 구성하는 요소들을 결정
2) 객체들 간의 관계 살펴보기
( 1번, 2번 과정이 도메인 모델로 구조를 표현한 것이다.)
3) 메세지를 통한 협력 설계. (메세지를 통해 메세지를 수신할 객체를 찾으면 해당 객체는 메세지를 처리할 책임을 할당받게 된다.)
( 3번 과정을 마치면 객체들의 인터페이스가 나온다.)
4) 동적인 객체들을 클래스를 이용해 정적으로 구현
