15. 디자인 패턴과 프레임워크

• 디자인 패턴은 협력을 일관성 있게 만들기 위해 재사용할 수 있는 설계의 묶음

• 프레임워크는 일관성 있는 협력을 제공하는 확장 가능한 코드

패턴의 정의

내가 사용하는 패턴 정의는 하나의 실무 컨텍스트에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어다. 아이디어라는 용어를 사용하는 이유는 어떤 것도 패턴이 될 수 있기 때문이다.— 마틴 파울러

• 패턴은 경험의 산물이다. 책상 위에서 탄생한 이론이나 원리와 달리 패턴은 치열한 실무 현장의 역학관계 속에서 검증되고 입증된 자산이다. 따라서 실무 경험이 적은 초보자라고 하더라도 패턴을 익히고 반복적으로 적용하는 과정 속에서 유연하고 품질 높은 소프트웨어를 개발하는 방법을 익힐 수 있게 된다.

패턴의 분류

• 분석 패턴

• 아키텍처 패턴 : 디자인 패턴의 상위로, 소프트웨어의 전체적인 구조를 결정하기 위해 사용할 수 있음
• 아키텍처 패턴은 미리 정의된 서브시스템들을 제공하고, 각 서브시스템들의 책임을 정의하며 서브시스템들 사이의 관계를 조직화하는 규칙과 가이드라인을 포함함.
• 아키텍처 패턴은 구체적인 소프트웨어 아키텍처를 위한 템플릿을 제공하며, 디자인 패턴과 마찬가지로 프로그래밍 언어나 프로그래밍 패러다임에 독립적임

• 디자인 패턴 : 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술함

• 이디엄 : 디자인 패턴의 하위로, 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴임. 주어진 언어의 기능을 사용해 컴포넌트, 혹은 컴포넌트 간의 특정 측면을 구현하는 방법을 서술함

디자인 패턴

• 어떤 구현 코드가 어떤 디자인 패턴을 따른다고 이야기할 때는 역할, 책임, 협력의 관점에서 유사성을 공유한다는 것이지 특정한 구현방식을 강제하는 것은 아니라는 점을 이해하는 것이 중요함

• 디자인 패턴은 단지 역할과 책임, 협력의 템플릿을 제안할 뿐 구체적인 구현 방법에 대해서는 제한을 두지 않음

• TEMPLATE METHOD 패턴 : 변경하지 않는 부분은 부모 클래스로, 변하는 부분은 자식 클래스로 분리함으로써 변경을 캡슐화. 알고리즘을 캡슐화하기 위해 합성 관계가 아닌 상속 관계를 사용하는 것을 템플릿 메서드 패턴
• 부모 클래스가 알고리즘의 기본 구조를 정의하고 구체적인 단계는 자식 클래스에서 정의하게 함으로 변경을 캡슐화 할 수 있는 디자인 패턴. 다만 합성보다는 결합도가 높은 상속을 사용했기에 STRATEGY 패턴처럼 런타임에 객체의 알고리즘을 변경하는 것은 불가능함.

• 디자인 패턴에서 중요한 것은 디자인 패턴의 구현 방법이나 구조가 아니다. 어떤 디자인 패턴이 어떤 변경을 캡슐화 하는지를 이해하는 것이 중요하다.

• 패턴을 사용하면서 부딪히게 되는 대부분의 문제는 패턴을 맹목적으로 사용할 때 발생함. 컨텍스트의 적절성은 무시한 채 패턴의 구조에만 초점을 맞추는 것
• 패턴에 처음 입문한 사람들은 패턴의 강력함에 매료된 나머지 아무리 사소한 설계라도 패턴을 적용해 보려고 시도한다. 그러나 명확한 트레이드오프 없이 패턴을 남용하면 설계가 불필요하게 복잡해지게 된다.

프레임워크

• 프레임워크는 코드를 재사용함으로써 설계 아이디어를 재사용한다.

• 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계 or 애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션의 골격 을 의미함

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

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

• 동일한 역할을 수행하는 객체들 사이의 협력 구조를 다양한 애플리케이션 안에서 재사용 하고자 하는 것이 핵심 ⇒ 변하는 것과 변하지 않는 것을 서로 분리해야 하고, 변하지 않는 것은 상위 정책에 속하는 역할들의 협력 구조임
• 상위 정책을 구현하고 있는 패키지가 세부 사항을 구현한 패키지로부터 완벽하게 분리되면, 상위 정책을 구현하고 있는 패키지를 다른 애플리케이션에서 재사용할 수 있게 됨 ↔ 컨텍스트 독립성의 패키지 버전

• 상위 정책 패키지와 하위 정책 패키지를 물리적으로 완전히 분리하고 나면 상위 정책 패키지를 여러 어플리케이션에서 재사용할 수 있는 기반이 마련된 것. 다시 말해 재사용 가능한 요금 계산 로직을 구현한 프레임워크가 만들어지는 것.

제어 역전 원리

• 의존성 역전 원리에 따라 구축되지 않은 시스템은 협력 흐름을 재사용할 수도 없으며 변경에 유연하게 대처할 수도 없다.

• 시스템이 진화하는 방향에는 항상 의존성 역전 원리를 따르는 설계가 존재해야 한다.

• 만약 요구사항이 빠르게 진화하는 코드에서 의존성 역전 원리가 적절하게 지켜지지 않고 있다면 그곳에는 변경을 적절하게 수용할 수 없는 하향식의 절차적인 코드가 존재할 수 밖에 없다.

좋은 객체지향 설계의 증명이 바로 이와 같은 의존성의 역전이다. 프로그램의 의존성이 역전돼 있다면, 이것은 객체지향 설계를 갖는 것이다. 의존성이 역전돼 있지 않다면, 절차적 설계를 갖는 것이다. 이 원칙은 또한 변경에 탄력적인 코드를 작성하는 데 있어 결정적으로 중요하다. 추상화와 구체적인 사항이 서로 고립돼 있기 때문에 이 코드는 유지보수하기가 훨씬 쉽다 — 로버트 마틴