[오브젝트 : chap15] 디자인 패턴과 프레임워크

[오브젝트] chap15을 읽고

협력 패턴을 일관되게 유지해야 한다. 협력 패턴에 관하여 언급할 가치가 있는 두가지 개념이 있는데 디자인 패턴과 프레임워크이다.

과거의 어떤 요구사항을 해결하기 위해 했던 방법과 유사한 해결 방법을 다시 사용하는 경우가 있다. 이처럼 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부른다.

디자인 패턴의 목적은 설계를 재사용하는 것이다. 디자인 패턴은 다양한 변경을 다루기 위해 반복적으로 재사용할 수 있는 설계의 묶음이다. 디자인 패턴을 익히면 변경의 방향과 주기를 이해하는 것만으로도 협력 방식을 순간적으로 떠올릴 수 있게 된다.

프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다. 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 다양한 환경에서 테스트를 거친 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다. 프레임워크의 확장포인트를 이용해 요구사항을 적절하게 구현할 수 있다.

• 디자인 패턴은 특정한 변경을 일관성있게 다룰 수 있는 협력 템플릿을 제공한다.
• 프레임워크는 특정한 변경을 일관성있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공한다.

디자인 패턴과 설계 재사용

지금 이 이 시간에도 패턴의 개념은 다양한 각도에서 정립되고 있다. 하지만 가장 중요한 것은 패턴의 이름이다. 이름 자체가 지식 전달과 커뮤니케이션 수단으로 활용되기 때문이다.

“인터페이스를 하나 추가하고 이 인터페이스를 구체화하는 클래스를 만든 후 객체의 생성자나 setter 메서드에 이를 할당해 런타임에 알고리즘을 바꿀 수 있게 하자”가 STRATEGY 패턴을 적용하자는 단순한 대화로 바뀐다.

패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다. 중요한 것은 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다는 사실이다. 특정한 상황을 마주치면 책임 주도 설계의 절차를 따르지 않고도 역할, 책임, 협력 관계를 손쉽게 구성할 수 있다.

패턴의 구성 요소는 클래스가 아니라 ‘역할’이다. 즉, 특정한 구현 방식을 강제하지 않는다는 것이다. 현재의 구조를 패턴에 맞추는것이 아니라 패턴의 기본 구조로부터 출발해 현재의 요구에 맞게 구조를 수정해야한다. 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 목적에 맞게 패턴을 수정하자.

각 디자인 패턴은 특정한 변경을 캡슐화하기 위한 독자적인 방법과 구조를 정의하고 있다. 이를 컨텍스트의 적절성을 무시한 채 맹목적으로 따르면 불필요하게 복잡하고 난해하며, 유지보수하기 어려운 시스템을 낳는다.

정당한 이유 없이 사용된 모든 패턴은 설계를 복잘하게 만드는 장애물이다. 복잡성의 가치가 단순성을 넘어설 때만 사용되어야 한다.

프레임워크와 코드 재사용

디자인 패턴은 설계를 재사용하는 것이지 코드를 재사용하지 않는다. 가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것이다. 이에 대한 답이 프레임워크이다. 프레임워크는 현재의 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션의 골격이다.

프레임워크의 핵심은 추상 클래스나 인터페이스와 같은 추상화라고 할 수 있다. 협력을 일관성있고 유연하게 만들기 위해서는 가급적이면 프레임워크의 추상 클래스나 인터페이스를 향하도록 작성해야 한다.

구체적인 클래스는 추상적인 클래스에 의존하지만, 추상적인 클래스는 구체적인 클래스에 의존하지 않는 의존성 역전 원칙을 지키도록 만들어진 것이다. 이 추상 클래스의 모임이 프레임워크인 것이다. 14장에서 구현한 변하지 않는 클래스들의 모임을 한 패키지에 넣는다면 요금 계산 로직을 구현한 패키지 단위의 프레임워크가 완성되는 것이다.

의존성 역전 원칙은 프레임워크의 가장 기본적인 설계 메커니즘이다. 의존성 역전은 의존성의 방향뿐만 아니라 제어 흐름의 주체 역시 역전시킨다. 전통적인 구조와 달리 프레임워크는 서브클래스의 메서드를 호출한다. 즉, 제어의 주체가 상위 정책인 프레임워크가 된다. 이를 제어 역전 원리라고 한다.

객체지향 시대에는 그저 프레임워크가 호출하는 코드를 작성해야만 한다. 제어가 우리에게서 프레임워크로 넘어가 버린 것이다. 제어의 역전은 프레임워크의 핵심 개념이자 코드의 재사용을 가능하게 하는 힘이라는 사실을 이해해야 한다.