15장 디자인 패턴과 프레임워크
오브젝트의 15장을 요약한 내용 입니다.
디자인 패턴이란?
소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 적용할 수 있는 해결 방법
디자인 패턴을 익히고 나면
변경의 방향과주기를 이해하는 것만으로도 필요한 역할과 책임, 역할 들의 협력 방식을 순간적으로 적용할 수 있다.디자인 패턴과 프레임워크의 차이
디자인 패턴은 특정한 변경을 일관성 있게 다룰 수 있는 협력 템플릿을 제공한다.
프레임워크는 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공한다.
디자인 패턴과 설계 재사용
패턴이란 무엇인가?
패턴은 반복적으로 발생하는
문제와해법의 쌍으로 정의된다.패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며,
이 지식을 다른 사람과
의사소통할 수 있다.패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워 주며 실질적인 코드 작성을 돕는다.
패턴의 요점은
패턴이 실무에서 탄생했다는 점이다.마틴 파울러가 언급한 것처럼 패턴의 범위가 소프트웨어 개발과
직접적인 연관성을 가진 분석, 설계, 구현 영역만으로 한정되는 것은 아니다.다양한 크기의 프로젝트 조직을 구성하는 방법, 프로젝트 일정을 추정하는 방법, 스토리 카드나 백로그를 통해 요구사항을 관리하는 방법과 같이 반복적인 규칙을 발견할 수 있는 모든 영역이 패턴의 대상이 될 수 있다.
패턴은 홀로 존재하지 않는다. 특정 패턴 내에 포함된 컴포넌트와 컴포넌트 간의 관계는 더 작은 패턴에 의해 서술될 수 있으며, 패턴들을 포함하는 더 큰 패턴 내에 통합될 수 있다.
패턴 분류
분석 패턴 :
도메인내의 개념 적인 문제를 해결하는 데 초점을 맞춘다.디자인 패턴 : 중간 규모의 패턴으로 특정한 설계 문제를 해결하는 것을 목적으로 하며, 프로그래밍 언어나 프로그래밍 패러다임에 독립적이다.
이디엄 : 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴으로, 주어진 언어의 기능을 사용해
컴포넌트, 혹은 컴포넌트 간의 특정 측면을 구현하는 방법을 서술한다.
특정한 상황에 적용 가능한 패턴을 잘 알고 있다면 책임 주도 설계의 절차를 하나하나 따르지 않고도 시스템 안에 구현할 객체들의 역할과 책임, 협력 관계를 빠르고 손쉽게 구성할 수 있다.
STRATEGY / TEMPLATE METHOD / DECORATOR 패턴 적용 예제
STRATEGY패턴
알고리즘의 변경을
캡슐화하는 것이고 이를 구현하기 위해 객체합성을 이용한다.
아키텍처 패턴
소프트웨어의 전체적인 구조를 결정하기 위해 사용, 미리 정의된 서브 시스템들을 제공하고, 각 서브 시스템들의 책임을 정의하며, 서브 시스템들 사이의 관계를 조직화하는
규칙과가이드라인을 포함한다.TEMPLATE METHOD 패턴
알고리즘을 캡슐화하기 위래 합성 관계가 아닌
상속 관계를 사용하기 위함
합성보다는 결합도가 높은 상속을 사용했기 때문에 strategy 패턴처럼 런타임에 객체의 알고리즘을 변경하는것은 불가능하다. 하지만 알고리즘 교체와 같은 요구사항이 없다면 상대적으로 strategy 패턴보다 복잡도를 낮출 수 있다는 면에서는 장점이라고 할 수 있다.
DECORATOR 패턴
객체의 행동을
동적으로추가할 수 있게 해주는 패턴으로서 기본적으로 객체의 행동을 결합하기 위해 객체 합성을 사용한다. 또한 선택적인 행동의 개수와 순서에 대한 변경을 캡슐화 할 수 있다.
패턴은 출발점이다
망치를 들면 모든 것이 못으로 보인다는 격언처럼 패턴을 익힌 후에는 모든 설계 문제를 패턴으로 해결하려고 시도하기 쉽다. 조슈아 케리에브스키는 이를 '패턴 만능주의'라고 부른다.
이렇게 되면 부적절한 상황에서 부적절하게 사용된 패턴으로 인해 소프트웨어의 엔트로피가 증가하는 부작용을 낳기 쉽다. 패턴을 남용하지 않기 위해서는 다양한 트레이드 오프 관계 속에서 패턴을 적용하고 사용해 본 경험이 필요하다.
전문가와 초심자의 또 다른 차이점은 전문가는 다양한 실무 경험을 통해 어떤 컨텍스트 에서 어떤 패턴을 적용해야 하는지, 그리고 이보다 더 중요한 것으로 어떤 패턴을 적용해서는 안 되는지에 대한 감각을 익히고 있다는 점이다.
타당한 이유 없이 패턴을 적용하면 패턴에 익숙한 사람들의 경우에는 설계의 의도를 이해하지 못하게 되고, 패턴을 알지 못하는 사람들은 불필요하게 복잡한 설계를 따라가느라 시간을 낭비하게 된다.
패턴을 적용할 때는 함께 작업하는 사람들이 패턴에 익숙한지 여부를 확인하고, 그렇지 않다면 설계에 대한 지식과 더불어 패턴에 대한 지식도 함께 공유 하는 것이 필요하다.
제어 역전 원리
객체지향 설계의 재사용성은 개별 클래스가 아니라 객체들 사이의 공통적인 협력 흐름으로 부터 나온다.
의존성 역전 원리에 따라 구축되지 않은 시스템은 협력 흐름을 재사용 할 수도 없으며 변경에 유연하게 대처할 수도 없다. 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전 원리 또는 할리우드 원리라고 한다.
우리의 코드는 수동적인 존재다. 프레임 워크가 우리의 코드를 호출해 줄 때까지 그저 넋 놓고 기다리고 있을 수밖에 없다. 할리우드에서 캐스팅 담당자가 오디션을 보러 온 배우에게 "먼저 연락하지 마세요. 저희가 연락 드리겠습니다"라고 말하는 것처럼 프레임 워크는 자신을 찾지 말라고 이야기한다.
제어의 역전이 프레임 워크의 핵심 개념인 동시에 코드의 재사용을 가능하게 하는 힘이라는 사실을 이해해야 한다.
Last updated
