오브젝트 chapter15

디자인 패턴과 프레임워크

디자인 패턴 : 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법

디자인 패턴의 목적은 설계를 재사용하는 것이다. 디자인 패턴과 프레임워크 모두 협력을 일관성 있게 만들기 위한 방법이다.

1. 디자인 패턴과 설계 재사용

패턴 정의는 하나의 실무 컨텍스트에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어다.

패턴이 지닌 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점이다.

패턴은 지식 전달과 커뮤니케이션의 수단으로 활용할 수 있기 때문에 패턴에서 가장 중요한 요소는 패턴의 이름이다.

패턴 분류

디자인 패턴

• 특정 정황 내에서 일반적인 설계 문제를 해결
• 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술
• 중간 규모 패턴
• 특정한 설계 문제를 해결하는 것을 목적
• 프로그래밍 언어나 프로그래밍 패러다임에 독립적

아키텍처 패턴

• 소프트웨어의 전체적인 구조를 결정하기 위해 사용
• 미리 정의된 서브시스템들을 제공
• 각 서브시스템들의 책임을 정의
• 서브시스템들 사이의 관계를 조직화하는 규칙과 가이드라인을 포함

이디엄

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

분석 패턴

• 도메인 내의 개념적인 문제를 해결하는 데 초점
• 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합

패턴과 책임-주도 설계

객체지향 설계에서 가장 중요한 일은 올바른 책임을 올바른 객체에게 할당하고 객체 간의 유연한 협력 관계를 구축하는 일이다.

패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다. 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다. 패턴의 구성 요소는 클래스가 아니라 역할이다.

디자인 패턴의 구성요소가 클래스와 메서드가 아니라 역할과 책임이라는 사실을 이해하는 것이 중요하다. 어떤 디자인 패턴을 따른다고 이야기할 때는 역할, 책임, 협력의 관점에서 유사성을 공유한다는 것이지 특정한 구현 방식을 강제하는 것은 아니라는 점을 이해하는 것이 중요하다. 디자인 패턴은 단지 역할과 책임, 협력의 템플릿을 제안할 뿐 구체적인 구현 방법에 대해서는 제한을 두지 않는다.

캡슐화와 디자인 패턴

대부분의 디자인 패턴은 협력을 일관성 있고 유연하게 만드는 것을 목적으로 한다.

• STRATEGY 패턴 : 알고리즘의 변경을 캡슐화하는 것. 객체 합성을 이용.
• TEMPLATE METHOD 패턴: 알고리즘을 캡슐화하기 위해 합성 관계가 아닌 상속 관계를 사용.
  • 부모 클래스가 알고리즘의 기본 구조를 정의하고 구체적인 단계는 자식 클래스에서 정의하게 함으로써 변경을 캡슐화할 수 있는 디자인 패턴.
• DECORATOR 패턴 : 객체의 행동을 동적으로 추가할 수 있게 해주는 패턴.
  • 기본적으로 객체의 행동을 결합하기 위해 객체 합성을 사용
  • 선택적인 행동의 개수와 순서에 대한 변경을 캡슐화 할 수 있다.
• COMPOSITE 패턴 : 개별 객체와 복합 객체라는 객체의 수와 관련된 변경을 캡슐화하는 것이 목적

패턴은 출발점이다

패턴은 설계의 목표가 돼서는 안 된다. 패턴은 단지 목표로 하는 설계에 이를 수 있는 방향을 제시하는 나침반에 불과하다. 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 패턴을 그대로 따르지 말고 목적에 맞게 패턴을 수정해라.

해결하려는 문제가 아니라 패턴이 제시하는 구조를 맹목적으로 따르는 것은 불필요하게 복잡하고, 난해하며, 유지보수하기 어려운 시스템을 낳는다. 패턴을 남용하지 않기 위해서는 다양한 트레이드오프 관계 속에서 패턴을 적용하고 사용해 본 경험이 필요하다.

전문가는 다양한 실무 경험을 통해 어떤 컨텍스트에서 어떤 패턴을 적용해야 하는지, 더 중요한 것으로 어떤 패턴을 적용해서는 안 되는지에 대한 감각을 익히고 있다는 점이다.

타당한 이유 없이 패턴을 적용하면 패턴에 익숙한 사람들의 경우에는 설계의 의도를 이해하지 못하게 되고, 패턴을 알지 못하는 사람들은 불필요하게 복잡한 설계를 따라가느라 시간을 낭비하게 된다.

패턴을 적용할 때는 항상 설계를 좀 더 단순하고 명확하게 만들수 있는 방법이 없는지를 고민해야 한다. 또한 코드를 공유하는 모든 사람들이 적용된 패턴을 알고 있어야 한다. 패턴을 알고 있는 사람들은 코드를 쉽게 이해할 수 있지만 그렇지 못한 사람들은 복잡한 구조로 인해 코드를 쉽게 이해할 수 없게 된다.

프레임워크와 코드 재사용

코드 재사용 대 설계 재사용

디자인 패턴은 프로그래밍 언어에 독립적으로 재사용 가능한 설계 아이디어를 제공하는 것을 목적으로 한다.

가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것이다.

프레임워크

• 구조적 측면: 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계
• 사용 목적: 코드와 설계의 재사용

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

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

추상 클래스와 인터페이스가 일관성 있는 협력을 만드는 핵심 재료이다.

상위 정책은 상대적으로 변경에 안정적이지만 세부 사항은 자주 변경된다. 상위 정책이 세부 사항에 비해 재사용될 가능성이 높다. 상위 정책이 세부 사항보다 더 다양한 상황에서 재사용될 수 있어야 한다. 하지만 상위 정책이 세부 사항에 의존하게 되면 상위 정책이 필요한 모든 경우에 세부 사항도 항상 함께 존재해야 하기 때문에 상위 정책의 재사용성이 낮아진다.

의존성 역전 원칙의 관점에서 세부 사항은 변경을 의미한다. 동일한 역할을 수행하는 객체들 사이의 협력 구조를 다양한 애플리케이션 안에서 재사용하는 것이 핵심이다. 변하는 것과 변하지 않는 것을 서로 분리해야 한다. 변하지 않는 것은 상위 정책에 속하는 역할들의 협력 구조다.

변하는 부분과 변하지 않는 부분을 별도의 패키지로 분리해야 한다. 중요한 것은 패키지 사이의 의존성 방향이다.

제어 역전 관리

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

의존성 역전 원리는 프레임워크의 가장 기본적인 설계 메커니즘이다. 의존성 역전은 의존성의 방향뿐만 아니라 제어 흐름의 주체 역시 역전시킨다. 이를 제어 역전 원리, 또는 할리우드 원리 라고 한다.

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

협력을 제어하는 것은 프레임워크다.