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

프레임워크 제작자

• 프레임워크 제작자는 나를 위해서가 아니라 자신이나 자신의 동료와 친구들의 문제를 해결하기 위해 프레임워크를 제작한다.

혼인 관계의 비대칭성

• 나는 프레임워크를 위해 헌신해야 하지만, 프레임워크 제작자는 나를 위해 헌신하지 않는다.
• 대개의 경우 프레임워크 제작자들은 나의 애플리케이션이 가능하면 프레임워크에 공고하게 결합될 것을 강하게 역설한다.

위험요인

• 이러한 프레임워크 특성의 위험요인은 무엇인가?
  • 프레임워크 아키텍처가 그다지 깔끔하지 않을 수 있다.
    • 프레임워크는 의존성 규칙을 위반하는 경향이 있다.
    • 프레임워크 객체 상속시 영원히 묶여 버리게 되어 헤어나오지 못할 수있다..
  • 애플리케이션 초반에는 도움이 되겠지만 시간이 지나면서 제품은 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것이다.
  • 프레임워크는 나에게 도움되지 않는 방향으로 진화할 수도 있다.
    • 신규 버전이 다른 일을 못하게 할 수도 있다.
  • 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있다.

해결책

• 프레임워크와 결혼하지 말라!
• 프레임워크를 아키텍처 바깥 원에 속하는 세부사항으로 취급하여 원 안으로 들어오지 못하게 하라!
• 업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구한다면 거절하고, 대신 프락시를 만들어 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 프락시를 위치시켜라.
  • 예를 들어 Spring 사용시, 업무 객체보다는 메인 컴포넌트에서 스프링을 사용해서 의존성을 주입하는 편이 낫다.(Spring은 의존성 주입 프레임워크)
• 프레임워크가 핵심 코드 안으로 들어오지 못하게 하라.
  • 대신 핵심 코드에 플러그인할 수 있는 컴포넌트에 프레임워크를 통합하고, 의존성 규칙을 준수하라.

이제 선언합니다

• 정말 결혼해야 하는 프레임워크도 있다.
  • C++ 과 STL / 자바와 표준 라이브러리
• 그러나 선택적이어야 한다.
• 프레임워크를 사용한다는 뜻은 애플리케이션이 프레임워크와 결혼한다는 의미이기 때문에 신중하게 선택해야 한다.