발전하는 프레임워크

구현 스타일을 사용하려면 추상화된 개념은 인터페이스로 전달해야 하는지 상위클래스로 전달해야하는지 결정해야한다.

인터페이스를 클라이언트에게 제공할때의 이점은 세부사항을 가급적 적게 드러낸다는 것이다.

단점은 인터페이스가 수정이 되면 구현하지 않는 경우 구현이 동작하지 않게 된다(java 8부터 default 메소드가 생김)

인터페이스에 복잡도를 증가시며서 유연성을 증대시키는 버전 인터페이스가 있다.

클라이언트가 프레임워크에 특정 클래스나 특정 클래스의 하위클래스의 인스턴스를 전달하게 할 수도 있다.

상위클래스에 새로운 메소드를 추가해도 호환성에 문제가 발생하지 않는다 하지만 클라이언트 클래스는 단하나의 프레임워크 클래스만 상속할 수 있다.

클라이언트에게 공개되는 상위클래스의 세부사항은 공용 및 보호 메소드와 필드이다.

abstract - 클라이언트에게 어떤 로직을 제공해야 하는지 알려줄수 있다.

final - 키워드 클래스에 사용하면 하위클래스를 생성할 수 없게 되어 인스턴스화냐 설정 스타일중 한가지 방법으로
프레임워크를 사용해야만 한다. 메소드에 사용하면 클라이언트에 언제나 어떤 메소드가 수행될지 보장해준다.

인스턴스화 방법을 정할 때는 일반성,복잡도, 사용의 용이성, 발전의 용이성 등을 모두 고려해야 한다.

가장 단순하고 유용성이 떨어지는 옵션은 클라이언트가 프레임워크 객체를 생성하는 것을 금지하는것

프레임워크는 프레임워크 개발자가 예측하지 못한 방식으로 유용하게 사용될 수도 있다.
따라서 객체 생성을 금지하는 경우 프레임 워크의 가치를 더욱 높일 수 있는 기회를 잃을 수도 있다.

객체를 생성자를 통새 생성하게 하는 것은 간단하지만, 이는 이휴 프레임워크 수정에 상당한 제약을 가져온다.

정적 공장을 사용하면 클라이언트가 객체를 생성하는 복잡도가 상당히 증가하지만
프레임워크 개발자는 미래의 설계 수정에 유연성을 갖게 된다.

정적 메소드를 호출하는 대신 공장 객체에 메시지를 보내서 인스턴스를 생성하는 방법도 있다.

공장 객체를 전역적으로 사용한다면 공장 객체는 정적 공장 메소드보다 나을것이 없다

공장 객체는 지역적으로 사용해야 좀더 효과적이다.

프레임워크 에서 객체 생성을 어떻게 하느냐는 프레임워크 사용과 수정의 용이성에 영향을 준다.

클라이언트가 문제를 해결할 수 있도록 하되 가급적 세부사항은 적게 노출해야 한다.

이미 공개된 메소드에 파라미터를 추가할 경우에는 호환성을 유지하기 위해 기본 값을 제공하라

참조