p. 250 ~ p. 263
변경을 기준으로 선택하라
단순히 클래스를 구현 단위로 사용하는 것이 객체지향 프로그래밍을 한다는 것을 의미하지 않는다. 타입을 기준으로 절차를 추상화하지 않는다면 객체 지향 분해가 아니다.
클래스가 추상 데이터 타입을 따르는지 확인할 수 있는 간단한 방법 → 클래스 내부에 인스턴스 타입을 표현하는 변수가 있는지 → 인스턴스 변수에 저장된 값을 기반으로 메서드 내에서 타입을 명시적으로 구분하는 방식은 객체 지향 위반
객체 지향에서는 타입 변수를 이용한 조건문을 다형성으로 대체
새로 추가된 클래스의 메서드를 실행하기 위한 어떤 코드도 추가할 필요가 없다 → 기존 코드에 영향 x (개방-폐쇄 원칙)
새로운 타입을 빈번하게 추가해야 한다면 객체 지향의 클래스 구조가 유용하고 새로운 오퍼레이션을 빈번하게 추가해야 한다면 추상 데이터 타입을 선택하는 것이 현명
협력이 중요하다
객체지향에서 중요한 것은 역할, 책임, 협력
객체가 참여할 협력을 결정하고 협력에 필요한 책임을 수행하기 위해 어떤 객체가 필요한지 고민해라
8. 의존성 관리하기
협력을 필수적이지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 한다. → 이런 관점에서 의존성을 관리하고 객체가 변화를 받아들일 수 있게 의존성을 정리하는 기술이 객체 지향 설계
8-1. 의존성 이해하기
변경과 의존성
실행 시점 : 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시 의존 대상 객체가 반드시 존재
구현 시점 : 의존 대상 객체가 변경될 경우 의존 객체도 함께 변경
어떤 객체가 예정된 작업을 정상 적으로 수행하기 위해 다른 객체를 필요로 하는 것 → 의존성
의존성은 변경에 의한 영향의 전파 가능성 암시
의존성이 가지는 근본적인 특성은 자신이 의존하는 대상이 변경될 때 함께 변경될 수 있다는 것
의존성 전이
의존하는 대상에 대해서도 자동적으로 의존하게 될 수 있다.
의존성의 전이 여부는 변경의 방향과 캡슐화의 정도에 따라 달라진다.
직접 의존성 : 말 그대로 한 요소가 다른 요소에 직접 의존하는 경우를 가리킨다.
간접 의존성 : 의존성 전이에 의해 영향이 전파되는 경우
의존성이란 의존하고 있는 대상의 변경에 영향을 받을 수 있는 가능성
런타임 의존성과 컴파일타임 의존성
컴파일 타임 의존성 : 시간이 아닌 우리가 작성한 코드의 구조
객체지향 애플리케이션에서 런타임의 주인공은 객체 → 런타임 의존성의 주제는 객체 사이의 이존성
코드 관점에서 주인공은 클래스 → 컴파일 의존성이 다루는 주제는 클래스 사이의 의존성
코드 작성 시점은 구현 클래스의 존재는 모르지만 실행 시점에는 협력할 수 있게 된다.
어떤 클래스의 인스턴스가 다양한 클래스의 인스턴스와 협력하기 위해서는 협력할 인스턴스의 구체적인 클래스를 알아서는 안된다 (컴파일 타임에는) 이는 런타임에 해결해야 한다.
컨텍스트 독립성
클래스가 특정한 문맥에 강하게 결합될 수록 다른 문맥에서 사용하기 어려워진다. 특정 문맥에 대한 최소한의 가정 → 다른 문맥에서 재사용하기가 더 수월 → 컨텍스트 독립성
더 유연한 설계와 변경에 탄력적 대응
의존성 해결하기
컴파일타임 의존성을 실행 컨텍스트에 맞는 적절한 런타임 의존성으로 교체하는 것을 의존성 해결
- 객체를 생성하는 시점에 생성자를 통해 의존성 해결
- 객체 생성 후 setter 메서드를 통해 의존성 해결
실행 시점에 의존 대상을 변경할 수 있기 때문에 유연한 설계 가능 → 객체를 생성하고 의존 대상을 설정하기 전까지는 객체 상태가 불완전 - 메서드 실행 시 인자를 이용해 의존성 해결
협력 대상에 대해 지속적인 의존 관계를 맺을 필요 없이 메서드가 실행되는 동안만 일시적으로 의존관계 존재
더 좋은 방식은 생성자 방식과 setter방식을 혼합하는 것. 항상 객체를 생성할 때 의존성을 해결해서 완전한 상태의 객체를 생성한 후 필요에 따라 setter 메서드를 이용해 의존 대상을 변경
