32장 프레임워크는 세부사항이다

 

프레임워크 제작자

 

대다수의 프레임워크 제작자는 프레임워크 사용자가 풀어야 할 특별한 관심사를 염두에 두지 않지만 사용자의 문제와 프레임워크가 풀려는 문제와 꽤 많이 겹침.

(그만큼 많이 겹치기에 인기를 많이 끌었으며 겹치는 영역이 클수록 프레임워크는 실제로 더욱 유용해짐.)

 

 

 

혼인 관계의 비대칭성

 

프레임워크 제작자는 프레임워크사용자의 애플리케이션이 가능하면 프레임워크에 공고하게 결합될 것을 강하게 역설함.

결합되어 생기는 위험요소는 오롯이 사용자가 감수함.

이는 사실상 프레임워크 제작자는 사용자에게 프레임워크와 혼인하기를 요구한다고 볼 수 있으며

사용자는 프레임워크에 대해 장기간 헌신을 하지만 프레임워크 제작자는 그에 상응하는 헌신은 사용자에게 하지 않음.

→ 제작자는 프레임워크에 대해 절대적인 제어권을 쥐고있기 때문.

 

 

 

위험 요인

 

<프레임워크 사용자가 고려해야할 위험요인>

• 업무 객체(고유엔티티)를 만들 때, 프레임워크 제작자는 자신의 코드를 상속할 것을 요구하며 의존성 규칙을 위반하는 경향이 있음.
• 애플리케이션 초기 기능을 만드는 데는 도움이 되지만 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될것임.
• 프레임워크가 도움이 되지 않는 방향으로 진화할 수도 있음. ( 사용중이던 기능이 사라지거나 반영하기 힘든 형태로 변하게 되는경우)
• 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있음.

 

 

 

해결책

 

- 프레임워크는 아키텍처 바깥쪽 원의 세부사항으로 취급.

- 프레임워크가 핵심코드 안으로 들어오지못하게 하는대신 플러그인할수 있는 컴포넌트에 프레임워크를 통합시켜 의존성규칙을 준수.

- 의존성 주입을 위해 @Autowired 어노테이션을 사용하지만 이를 업무 객체 도처에 산재시켜서는 안됨.

   → 업무규칙이 스프링을 알아선안됨.

- 최저수준인 메인컴포넌트에 위치시켜 사용 권장.

 

 

 

이제 선언합니다.

 

정말로 결혼해야하는 프레임워크도 존재함. C++을 사용한다면 STL과 자바를 사용한다면 자바 표준라이브러리와 반드시 결혼해야함.

이러한 관계는 정상이지만 선택적이어야함.