ch.15 프레임워크와 코드 재사용

코드 재사용 대 설계 재사용

디자인패턴은 프로그래밍 언어에 독립적으로 재사용 가능한 설계 아이디어를 제공하는 것을 목적으로 한다. 따라서 언어에 종속적인 구현 코드를 정의하지 않기 때문에 프로그래밍 언어의 특성에 맞춰 가공해야 하고 매번 구현 코드를 재작성해야하는 단점이 있다.

 

재사용 관점에서 설계 재사용보다 더 좋은 방법은 코드 재사용이다. 

컴포넌트를 조립해서 애플리케이션을 구축하는 방법을 추구해왔다. 해당 아이디어는 이상적이지만 실제로 작용하는 과정에서 현실적이지 않다라는 사실이 드러났다.

 

프레임워크란 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계. 또는 애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징할 수 있는 애플리케이션의 골격을 의미한다. 즉 구조적인 측면에 초점과 코드의 재사용이라는 사용 목적에 초점을 맞춘다.

 

상위 정책과 하위 정책으로 패키지 분리하기

프레임워크의 핵심은 추상 클래스나 인터페이스와 같은 추상화라고 할 수 있다.

 

대부분의 의존성이 추상화를 향하는 일관성 있는 협력

짙은색은 추상화에 해당된다. 구체적 클래스는 RatePolicy, AdditionalRatePolicy, FeeCondition에 의존하지만 추상화들은 구체 클래스에 의존하지 않는다는 것을 할수 있다.

 

상위 정책이 구체적인 세부적인 사항에 의존하도록 소프트웨어를 구성한다. 

상위 정책은 변경에 안정적이지만 세부 사항은 자주 변경된다. 

요점은 상위 정책이 세부 사항보다 더 다양한 상황에서 재사용 될 수 있어야 한다는 것이다.

 

의존성 역전 원칙의 관점에서 세부 사항은 변경을 의미한다.

동일한 역할을 수행하는 객체들 사이의 협력 구조를 다양한 애플리케이션 안에서 재사용하는것이 핵심이다.

 

이를 위해서는 변하는 것과 변하지 않는 것을 서로 분리해야한다. 여기서 변하지 않는 것은 상위 정책에 속하는 역할들의 협력 구조이다.

 

상위  정책과 하위 정책을 별도의 패키지로 분리

중요한것은 패키지 사이의 의존성 방향이다. 의존성 역전 원리에 따라 추상화에만 의존하도록 의존성의 방향을 조정하고 추상화를 경계로 패키지를 분리했기 떄문에 세부 사항을 구현한 패키지는 항상 상위 정책을 구현한 패키지에 의존해야한다.

 

이제 상위 정책을 구현하고 있는 패키지가 분리 됐기때문에 해당 패키지를 다른 애플리케이션에 재사용할 수 있다는 것이다. 

 

별도의 배포 단위로 분리된 프레임워크

프레임워크는 여러 애플리케이션에 걸쳐 일관성 있는 협력을 구현할 수 있게 해준다. 우리는 동일한 프레임 워크를 사용하는 여러 애플리케이션에 걸쳐 일관성 있게 코드를 설계하고 구현할 수 있다. 추가적으로 일관적이기 떄문에 이해하기도 쉽고, 설계와 코드를 재사용가능하다.

 

제어 역전의 원리

상위 정책을 재사용한다는 것은 결국 도메인에 존재하는 핵심 개념들 사이의 협력 관계를 재사용한다는 것을 의미한다.

의존성 역전 원리는 전통적인 설계 방법과 객체지향을 구분하는 가장 핵심적인 원리다. 의존성 역전 원리에 따라 구축되지 않은 시스템은 협력 흐름을 재사용할 수도 없으며 변경에 유연하게 대처할수 없다.

 

좋은 객체지향의 증명이 바로 의존성 역전이다. 프로그램이 어떤 언어로 작성됐는가는 상관없다. 프로그램의 의존성이 역전돼 있다면, 이것은 객체지향 설계를 갖는 것이다.

 

의존성 역전 원리는 프레임워크의 가장 기본적인 설계 메커니즘이다. 의존성 역전은 의존성의 방향뿐만 아니라 제어 흐름의 주체 역시 역전 시킨다. 앞서 설명한 것처럼 상위 정책이 구체적인 세부사항에 의존하는 전통적인 구조에서는 상위정책의 코드가 하부의 구체적인 코드를 호출한다. 즉, 애플리케이션의 코드가 재사용 가능한 라이브러리나, 툴킷의 코드를 호출한다.

 

그러나 의존성을 역전시킨 객체지향 구조에서는 반대로 프레임워크가 애플리케이션에 속하는 서브클래스의 메서드를 호출한다. 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다. 즉 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전 원리, 할리우드 원리라고 한다.

 

호출 시점을 제어하는 프레임워크

프레임워크에서는 일반적인 해결책만 제공하고 애플리케이션에 따라 달라질 수 있는 특정한 동작은 비워둔다. 그리고 이렇게 완성되지 않은 채로 남겨진 동작을 훅이라고 부른다. 

재정의 된 훅은 제어 역전 원리에 따라 프레임워크가 원하는 시점에 호출된다.

 

라이브러리는 우리가 직접 호출했지만. 객체지향의 시대에서는 프레임워크가 호출하는 코드를 작성해야만한다. 제어가 우리에게서 프레임워크로 넘어간 것이다. 즉 제어가 역전된것이다.

 

라이브러리는 우리가 애플리케이션 자체가 언제 어떤 라이브러리를 사용할 것인지를 스스로 제어한다. 하지만 프레임워크를 재사용할때는 프레임워크가 제공하는 메인 프로그램을 재사용하고. 해당 메인 프로그램이 호출하는 코드를 애플리케이션 개발자가 작성한다. 즉 제어가 역전된 것이다. 개발자는 이미 특정 이름과 호출 방식이 결정된 오퍼레이션을 작성해야 하지만 결정해야 하는 설계 개념을 줄고 애플리케이션별로 구체적인 오퍼레이션의 구현만 남게 된다.

 

즉 라이브러리와 프레임워크에 가장 큰 차이는 제어의 역전이다.