[켄트벡의 구현패턴] ~ 195p 발전하는 프레임워크

- 프레임워크 개발시에는 기존에 설명했던 애플리케이션 개발의 경우와는 다르게 코드 수정에 드는 비용이 클 수도 있다. (프레임워크 개발자가 클라이언트 코드까지 수정할 수는 없으므로..)

프레임워크 버전업을 진행할 때 기존 코드와의 호환성도 고려해야 한다.

 

1. 애플리케이션 수정 없이 프레임워크 수정하기

- 프레임워크 수정시에는 기존 애플리케이션 개발에 있어서의 중요 덕목인 '단순성' 만을 강조할 수는 없다. '호환성'이 더 중요한 요소이다. (단순성도 중요하지 않다는 소리는 아니다. 여전히 중요하다.)

- 기존 클라이언트 코드의 동작을 보작하면서 프레임워크를 개선하기 위해서는 어느정도의 코드 복잡도는 올라갈 수 있다. 

 

2. 호환성 없는 업그레이드

- 프레임워크 업그레이드를 단계적으로 시행하여, 클라이언트측에서 새로운 프레임워크 버전으로 코드를 바꿀 수 있도록 시간을 주는 방식

- 업그레이드 후에도 기존 코드는 그대로 지원하는 경우도 있다.

- 위 두가지 경우 모두 클라이언트 측에서 업그레이드 시점을 결정할 수 있게 해준다.

 

3. 호환성을 유지하는 업그레이드

- 세부 구현을 드러내지 않은채 인터페이스 등으로만 프레임워크 코드를 노출한 경우, 세부 구현을 추후에 수정하더라도 클라이언트 코드엔 영향이 가지 않는다. 이런 식으로 코드를 짜면 추후 프레임워크 업그레이드나 설계 변화에 유연성을 얻을 수 있다.

 

- 라이브러리 클래스 : 라이브러리 클래스를 활용하여 정적 메소드를 제공하면 복잡도를 높이지 않고 유연성을 제공할 수 있다. 필요한 기능이 생기면 기존 기능과는 별도로 새로운 정적 메소드를 추가하기만 하면 된다.

다만, 필요한 기능이 다양해지고 변형이 생긴다면 이를 다 표현하기 힘들다는 단점이 있다.

 

- 객체 : 프레임워크를 객체로 나타낼 수 있다. 여기엔 네가지 이슈가 있다.

  -> 사용 스타일 : 프레임워크는 다음의 세가지 주요 스타일을 지원한다.

• 인스턴스화 : 객체 생성을 하는 방식으로 프레임워크를 사용할 수 있게 지원. 로직의 변형 필요 없이 데이터 변형만 필요한 경우 사용함.
• 설정 : 인스턴스화보다는 자신만의 객체를 프레임워크에 전달해서 사용할 수 있게 함. (ex Comparator 전달해서 정렬 처리)
• 구현 : 클라이언트측에서 아예 새로 구현해서 사용(ex Comparator를 커스터마이징해서 사용)

 

  -> 추상화 : 인터페이스와 상위클래스 방식으로 추상화를 사용 가능.

      인터페이스는 추상화된 내용만 전달하기 때문에 유연성이 좋다.

      상위클래스는 인터페이스보다 세부 사항을 나타낼 수 있으면서 새로운 메소드를 추가해도 호환성 문제가 없음.

      다만 인터페이스는 클라이언트 클래스에 여러개의 구현을 지원하지만, 상위클래스는 하나의 구현만 지원

 

  -> 생성 :  생성의 방법도 여러가지가 있음.

• 생성금지 : private로 생성자를 만들어서 클라이언트가 객체 생성 못하도록 함. -> 예측못할 호환성 문제 제거.  
• 생성자 :  생성자로 객체 생성하게 하는건 클라이언트 입장에서 보면 단순 명확함.
• 정적 공장 : 클라이언트가 객체를 생성하는 복잡도는 올라가지만, 프레임워크 개발자 입장에서는 미래의 설계 수정의 유연성 확보가 가능.    
• 공장 객체 : 정적 메소드 생성보다 유연성이 올라감. (공장 객체가 상황에 따라 다른 구현객체 구현 가능)

  -> 메소드 : 객체 생성시의 전략과 크게 다르지 않음. 설정메소드(+취득메소드)는 지양하는 것이 좋다.

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

                 (193p 예시 참조 다시보기)