발전하는 프레임워크
코드를 이해하고 커뮤니케이션하는 데 드는 비용에 비해 코드를 수정에 드는 비용이 훨씬 저렴하다고 가정했다.
애플리케이션 수정 없이 프레임워크 수정하기
프레임워크를 지속적으로 발전시켜야 하지만 기존 클라이언트 코드는 계속해서 동작하도록 해야한다는것
프레임워크 개발의 경제성을 향상시키려면 호환성이 유지되지 않는 업그레이드가 발생할 확률을 낮추도록하고 가
어쩔수 없이 호환성이 유지 되지 않는 업그레이드 필요한 경우 그 비용을 최소화 해야 한다.
호환성 없는 업그레이드
업그레이드를 여러단계로 나누면 클라이언트에게 앞으로 어떤 변화가 생길지 미리 알려주게 되어 언제 코드를 고쳐야 하는지 결정할 수 있게 해준다.
다른 점진적 업그레이드 전략은 API와 구현을 바꾸되 한번에 둘 모두를 바꾸지 않는것
자바는 기존코드가 앞으로도 계속 동작하는것을 보장해주지만 이클립스는 릴리즈 번호의 정부수분이 같은경우만 호환성을 보장해준다.
호환성을 유지하는 업그레이드
클라이언트 코드는 가급적 프레임워크의 세부 구현에 의존하지 않아야 한다.
후방 호환성 업그레이드 - 구형 메소드 호출과 구형 객체 전달을 지원할껀가?
전방 호환성 업그레이드 - 신형 스타일의 객체를 클라이언트에 전달해도 동작하도록 할껀가
라이브러리 클래스
라이브러리 클래스를 사용하면 복잡도를 높이지 않으면서도 미래에 대비할수 있다.
Collections 클래스는 라이브러리 클래스를 통해 API를 제공하는 좋은 예이다.
객체
프레임워크를 객체로 나타내는 경우 단순성과 복잡성 사이 유연성과 구체성 사이에서 균형을 잡기는 더욱 어려워진다.
프레임워크를 객체로 나타낼때에 네가지 이슈
- 사용 스타일 - 클라이언트가 프레임워크 객체를 인스턴스화 해서 사용할 것인가 아니면 확장시켜서(상속) 사용할것인가?
- 추상화 - 클래스 수준의 세부 사항을 인터페이스로 나타낼 것인가 클래스로 나타낼 것인가? 어떤 가시성을 사용할것인가?
- 생성 - 어떻게 객체를 생성하는가?
- 메소드 - 메소드를 어떻게 구성하면 클라이언트에게는 유용성을 프레임워크 개발자에게 유연성을 제공할수 있을까?
사용스타일
프레임워크는 인스턴스화, 설정, 구현의 세가지 주요 스타일을 지원한다.
- 인스턴스화 - 클라이언트가 로직의 변형을 필요하지 않고 데이터 변형만을 필요로 하는 경우 인스턴스화를 사용
- 설정 - 데이터 변경뿐 아니라 로직의 변형도 지원 해서 인스턴스화보다 유현
- 구현 - 미래에 있을 설계 변경을 가장 크게 제한한다. 호환성을 보장하기 위해서는 프레임워크에서 제공하는 상위클래스나 인터페이스를 그대로 유지해야 되기 때문이다.