Ch.15 디자인 패턴과 프레임워크
소프트웨어 패턴
소프트웨어 패턴은 실무 속에서 탄생했으며, 다른 실무 컨텍스트에서도 유용할 것으로 예상되는 아이디어이다 .
패턴은 지식 전달과 커뮤니케이션의 수단으로 활용될 수 있는데, 따라서 패턴의 가장 중요한 요소는 '이름'이다.
패턴은 소프트웨어 개발 뿐 아니라 반복적인 규칙을 발견할 수 있는 모든 영역이 패턴의 대상이 된다.
패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.
패턴 언어
크리스토퍼 알렉산더는 연관된 패턴의 집합이 모여 하나의 패턴 언어(Pattern Language)가 된다고 정의한다.
패턴 언어는 연관된 패턴 카테고리뿐만 아니라 패턴의 생성 규칙과 함께 패턴 언어에 속한 다른 패턴과의 관계 및 협력 규칙을 포함한다.
패턴 시스템(Pattern System)과 거의 동일한 의미로 사용된다.
패턴 분류
패턴의 범위와 적용 단계에 따라 아키텍처 패턴(Architecture Pattern), 분석 패턴(Analysis Pattern), 디자인 패턴(Design Pattern), 이디엄(Idiom)의 4가지로 분류된다.
디자인 패턴
개발하다보면 어떤 요구사항을 해결할 때 데자뷰처럼 과거에 경험했던 유사한 해결 방법을 그대로 사용하는 경우가 있다.
디자인 패턴은 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법이다.
협력을 일관성 있게 만들기 위한, "설계"를 재사용하기 위한 설계의 묶음이다.
패턴을 적용할 때 패턴에서 제시하는 구조(의 생김새)를 그대로 구현하는 것이 아니라, 프로젝트의 요구사항에 맞게 구조를 조정해서 적용할 수 있도록 한다.
주의사항
패턴은 설계의 목표가 되어서는 안된다.
디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 맞지 않다면 목적에 맞게 패턴을 수정해야 한다.
패턴을 처음 배우는 사람들은 망치를 들면 모든 것이 못으로 보인다는 격언처럼 모든 설계 문제를 패턴으로 해결하려고 시도하기 쉬운데, 이것을 '패턴 만능주의'라고 부른다.
정당한 이유 없이 사용된 모든 패턴은 설계를 복잡하게 만드는 장애물이며, 복잡성의 가치가 단순성을 넘어설 때만 정당화돼야 한다.
항상 설계를 좀 더 단순하고 명확하게 만들 수 있는 방법이 없는지를 고민해야 한다.
코드를 공유하는 모든 사람들이 적용되는 패턴을 알고 있어야 패턴을 적용할 수 있다.
조슈아 케리에브스키는 패턴을 가장 효과적으로 적용하는 방법은 패턴을 '지향'하거나 패턴을 '목표'로 리팩터링하는하는 것이라고 이야기한다.
프레임워크
일관성 있는 협력을 제공하는, "설계와 코드를 함께" 재사용하기 위한 확장 가능한 코드이다.
'설계를 재사용하면서도 유사한 코드를 반복적으로 구현하는 문제를 피할 수 있는 방법은 없을까?'에 대한 객체지향 커뮤니티의 대답이다.
'추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계',
또는 '애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징할 수 있는 애플리케이션의 골격(skeleton)'을 의미한다.
정리
디자인 패턴에 대해서 맛보기로 알아보았다. 적지는 않았지만 책에서 여태까지 설명한 예시들에는 STRATEGY, TEMPLATE METHOD, COMPOSITE 패턴 등 다양한 패턴이 적용되었다.
패턴이 설계의 목표가 되어서는 안된다는 말이 눈에 들어왔는데, 패턴을 섣불리 쓰다가 오히려 코드를 이해하는 데에 들어가는 리소스와 복잡성이 올라간다면 별로 좋지 않을 것 같다. 책에서도 꾸준히 나온 이야기이지만 정답은 없으니 상황에 맞게 하는 것이 바람직할 것으로 보인다.
Last updated