오브젝트

도서 링크: https://www.yes24.com/Product/Goods/74219491

설계 품질과 트레이드 오프

결국 책임이 객체지향 애플리케이션 전체의 품질을 결정하는 것

객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다.

데이터 중심의 영화 예매 시스템

객체의 상태는 구현에 속한다. 구현은 불안정하기 떄문에 변하기 쉽다.
결과적으로 상태 변경은 인터페이스의 변경을 초래하며 이 인터페이스에 의존하는 모든 객체에게 변경의 영향이 퍼지게 된다.
데이터 초점을 맞춘 설계는 변경에 취약할 수밖에 없다.

객체의 종류를 저장하는 인스턴스 변수와 인스턴스의 종류에 따라 베타적으로 사용될 인스턴스 변수를 하나의 클래스 안에 함꼐 포함시키는 방식은 데이터 중심의 설계안에서 흔히 볼수 있는 패턴

설계 트레이드 오프

캡슐화
상태와 행동을 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로부터 감추기 위해서이다.
여기서 구현이란 나중에 변경될 가능성이 높은 어떤 것을 가리킨다.
객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있다.

변경의 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스에만 의존하도록 관계를 조절하는 것까지는

설계가 필요한 이유 -> 요구사항이 변경되기 때문
캡슐화가 중요한 이유는 -> 불안정한 부분과 안정적인 부분을 분리해서변경의 영향을 통제할 수 있기 때문

응집도와 결합도

일반적으로 좋은 설계란? 높은 응집도와 낮은 결합도를 가진 모듈로 구성된 설계 === 오늘의 기능을 수행하면서 내일의 변경을 수용할 수 있는 설계

데이터 중심의 영화 예매 시스템의 문제점

데이터 중심의 설계는 캡슐화를 위반하고 객체의 내부 구현을 인터페이스의 일부로 만듬.
책임 중심의 설계는 객체의 내부 구현을 안정적인 인터페이스 뒤로 캡슐화가

접근자와 수정자 (getter, setter) 메서드는 객체 내부의 상태에 대한 어떤 정보도 캡슐화하지 못한다.
인스턴스 변수가 존재한다는 사실을 퍼블릭 인터페이스에 노골적으로 드러낸다.

구현을 캡슐화할 수 있는 적절한 책임은 협력이라는 문맥을 고혀할떄만 얻을 수 있음 객체가 사용될 문맥을 추측할 수 밖에 없는 경우 -> 해당 객체가 어떤 상황에서는 사용될 수 있게 최대한 많은 접근자 메서드를 추가하게 되는 것

접근자와 수정 자에 과도하게 의존하느 설계 방식을 추측에 의한 설계 전략

자율적인 객체를 향해

스스로 자신의 데이터를 책임지는 객체
우리가 상태와 행동을 객체라는 하나의 단위로 묶는 이유는 객체 스스로 자신의 상태를 처리할 수 있게 하기 위해

캡슐화의 진정한 의미
단순히 객체 내부의 데이터를 외부로부터 감추는 것 이상의 의미 변경될 수 있는 어떤 것이라도 감추는 것을 의미한다.

데이터 중심 설계의 문제점

• 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.
• 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.

객체의 행동보다 상태에 초점을 맞춘다. 데이터 중심의 관점에서 객체는 그저 단순한 데이터의 집합체이다.

데이터를 처리하는 작업과 데이터를 같은 객체안에 두더라도 데이터에 초점이 맞춰져 있다면 만족스러운 캡슐화를 얻기 힘들다.
데이터를 먼저 결정하고 데이터를 처리하는 데 필요란 오퍼레이션을 나중에 결정하는 방식은 데이터에 관련 지식이 객체의 인터페이스에 고스란히 드러나게 된다.