p65 ~ p77
추상화의 이점
- 요구사항의 정책을 높은 수준에서 서술할 수 있다.
→ 세부 내용을 제외하고 상위 정책을 쉽고 간단하게 표현할 수 있다. - 유연한 설계가 가능하다.
→ 추상화를 통해 정의한 상위 정책의 협력 흐름을 따르기 때문에 하위의 새로운 기능의 추가와 확장이 용이하다.
→ Java의 인터페이스, 추상 클래스를 통해 정의한 상위 정책을 의존할 경우 하위 기능을 추가하고 확장하고 실행단계에서 의존하도록 코드를 작성하면 되기 때문에 유연성 있는 설계가 가능하다.
하지만 이상적으로 인터페이스를 사용하도록 변경한 설계가 좋을 것이지만, 현실적인 비용으로 인터페이스를 추가하는 것이 과하다고 느껴질 수 있다. 인터페이스를 추가하지 않고 추상 클래스를 상속한 클래스들 만드로 코드의 의미 전달이 충분한 경우도 있기 때문이다.
실제 구현에서는 이상적인 설계 방식과 현실적인 비용이라는 트레이드 오프가 존재한다. 그에 대한 결정은 합리적인 이유가 존재해야 한다.
코드 재사용 - 합성
합성 : 다른 객체의 인스턴스를 자신의 인스턴스 변수로 포함해서 재사용 하는 것.
왜 상속 보다 합성을 선호할까
상속은 부모클래스를 구조를 알아야 자식 클래스에 대한 기능을 구현할 수 있기 때문에 캡슐화가 약화된다. → 부모클래스가 변경될 경우 자식 클래스도 변경될 수 있음 → 유연한 설계를 막음
합성은 인터페이스에 정의된 메시지를 통해서 재사용하기 때문에 구현을 효과적으로 캡슐화할 수 있다.또한 의존하는 인스턴스를 교체하는 것이 비교적 쉽다 → 유연한 설계
역할, 책임, 협력
객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다. → 너무 이른 시기에 구현에 초점을 맞추지 마라.
중요한 것은 역할, 책임, 협력
협력이란 하나의 기능을 구현하기 위해 다양한 객체들이 서로 메시지를 주고받으면서 상호작용하는 것이다.
책임이란 이 협력을 수행하기 위해 각각의 객채가 수행하는 로직이다.
역할이란 협력관계에서 각 객체의 책임들이 모여서 수행하는 기능이다.
협력
협력이란 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것이다. 요청하는 커뮤니케이션은 메시지를 전송하는 것이 유일하다. 객체는 다른 객체의 책임에 관여할 수 없기 때문이다.
협력 과정에서 객체들은 자율적은 존재로서 각각의 책임을 수행한다. 이때 자신이 수행할 수 없는 책임을 메시지를 전송함으로써 다른 객체에 위임하고, 객체는 자율적으로 책임을 수행하고 응답함으로써 협력을 완성한다.
이때 객체를 자율적으로 만드는 기본적인 방법이 내부구현의 캡슐화이다.
객체의 행동을 결정하는 것은 참여하는 협력이다.
애플리케이션에서 객체가 필요한 이유는 협력에 참여하기 위함이다. 역할을 수행하기 위해 협력을 진행하는 것이고 협력을 진행하기 위해 각각의 객체들은 책임을 수행하기 때문이다.
따라서 협력의 문맥을 고려하지 않고 객체를 설계하는 것은 잘못된 것이다.
객체가 어떤 상태를 가지고 있을지는 협력을 수행하기 위해 필요한 정보들에 따라 결정된다.
