이 글은 refactoring guru의 - What is a Pattern 부분을 읽고 번역 및 정리한 글입니다.
2021년 12월 28일부터 스터디 중독자들과 함께 디자인 패턴 스터디를 진행하기로 하였습니다. 이를 위해 refactoring.guru 사이트에서 디자인 패턴을 읽고 하나하나 정리해보려고 합니다.
깃헙 주소: study-driven-developer/design-pattern
디자인 패턴이란?
디자인 패턴은 소프트웨어 디자인에서 일상적으로 발생하는 문제에 대한 일반적인 해결책이다. 이 패턴들은 미리 만들어진 청사진과도 같은데, 커스터마이징하여 코드에서 반복되는 설계 문제를 해결할 수 있다.
기존에 존재하는 함수나 라이브러리들로 패턴을 찾아서 프로그램에 복사한다고 하여 패턴이 되는것은 아니다. 패턴은 특정 코드 조각이 아닌, 특정 문제를 해결하는 일반적인 개념이다. 패턴 세부 사항을 따라 자신의 프로그램에 맞는 솔루션을 구현할 수 있다.
패턴을 종종 알고리즘과 같은 거 아니야? 라고 헷갈려하는 분들이 있는데, 이 두가지 개념 모두 알려진 문제에 대한 일반적인 해결책을 설명하기 때문이다. 알고리즘은 항상 목표를 달성할 수 있는 일련의 명확한 작업을 정의하지만 패턴은 해결책에 대한 보다 높은 수준의 설명이라고 볼 수 있다. 따라서 서로 다른 두 프로그램에 적용되는 패턴이 동일하더라도, 코드는 다를 수 있다.
알고리즘과의 유사점은 요리 레시피라고 볼 수 있다. 패턴과 알고리즘 모두 목표를 달성하기 위한 명확한 단계를 가지고 있다. 반면에 패턴은 청사진에 가깝고, 결과와 그 특징을 확인할 수 있지만 정확한 구현 순서는 사용자에게 달려있다.
패턴은 무엇으로 구성되는가?
대부분의 패턴들은 사람들이 많은 맥락에서 재현할 수 있도록 형식적으로 설명된다. 아래는 패턴을 설명하기 위해 일반적으로 쓰이는 구조이며 이 책 또한 이 형식에 맞추어서 디자인 패턴들을 소개한다.
- 패턴의 의도(Intent)는 문제와 해결책을 간략하게 설명한다.
- 동기(Motivation)는 패턴의 가능성과 문제를 더 설명한다.
- 클래스의 구조(Structure)는 패턴의 각 부분과 그들이 어떻게 연관되어 있는지를 보여준다.
- 널리 사용되는 프로그래밍 언어로 작성된 디자인 패턴 코드 예제(Code example)는 패턴 뒤에 있는 아이디어를 쉽게 파악할 수 있도록 해준다.
일부 패턴 카탈로그는 패턴의 적용 가능성, 구현 단계 및 다른 패턴과의 관계와 같은 기타 유용한 세부 정보를 나열한다.
패턴의 역사
패턴은 누가 발명했는지 알 수 없다. 왜냐하면 디자인 패턴이 모호하고 정교한 개념이 아닌 객체 지향 설계의 일반적인 문제에 대한 솔루션이기 때문이다. 이 말은 즉슨, 솔루션이 여러 프로젝트에서 반복되면 결국 누군가가 솔루션에 이름을 붙이고 그에 대해 자세하게 설명한다. 이것이 일반적으로 패턴이 발견되는 방법이다.
패턴의 개념은 크리스토퍼 알렉산더의 A Pattern Language: Towns, Buildings, Construction.에서 처음 기술되었다. 이 책은 도시환경을 디자인하기 위한 '언어'를 설명한다. 이 언어의 단위는 패턴이고 창문이 얼마나 높아야 하는지, 건물이 몇 층을 가져야 하는지, 이웃에서 녹지가 얼마나 커야하는 지에 대해 설명한다.
이 패턴에 대한 아이디어는 네 명의 저자:Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm 에 의해 채택되었고, 1994년 그들은 Design Patterns: Elements of Reusable Object-Oriented Software을 출판했다. 재사용 가능한 객체지향 소프트웨어의 요소로서 설계 패턴의 개념을 프로그래밍에 적용했다. 이 책은 객체 지향 디자인의 다양한 문제를 해결하는 23가지 패턴을 담고있었고 빠르게 베스트셀러가 되었다. 이 책의 긴 이름 때문에 "4인조 책"이라고 부르기 시작했고, 곧 간단히 "GoF 책"으로 줄이게 되었다.
그 이후로, 수십 개의 다른 객체 지향적인 패턴이 발견되었다. "패턴 접근법"은 다른 프로그래밍 분야에서 매우 인기있기 때문에 객체 지향 디자인외에도 많은 패턴들이 존재한다.
왜 패턴을 배워야 하는가?
사실 당신은 어떠한 패턴도 모른 채 수년간 프로그래머로 일하게 될지도 모른다. 많은 사람들이 그렇고, 당신도 모르는 사이에 몇 가지 패턴을 구현하고 있을 수도 있다. 그럼에도 왜 배워야 하는 가?
-
디자인 패턴은 소프트웨어 설계의 일반적인 문제에 대해 시도되고 테스트된 솔루션의 툴킷이다. 이런 문제를 접하지 않더라도, 패턴을 아는 것은 객체지향적 디자인의 원리를 이용해 온갖 문제를 푸는 방법을 가르쳐주기 때문에 유용하다.
-
디자인 패턴은 사용자와 팀원들이 보다 효율적으로 의사소통하기 위해 사용할 수 있는 공통 언어를 정의한다. "그냥 싱글톤을 사용해봐"라고 말을 하였을 때, 디자인 패턴을 아는 사람들은 싱글톤이 무엇인지 설명하지 않고 당신의 말 뒤에 있는 아이디어를 이해할 것이다.
패턴에 대한 비판
패턴 사용에 반대하는 가장 일반적인 주장을 살펴보자.
약한 프로그래밍 언어에 대한 클러지
보통 패턴의 필요성은 사람들이 프로그래밍 언어나 추상화 수준이 부족한 기술을 선택할 때 발생한다. 이 경우 패턴은 언어에 매우 필요한 초능력을 주는 클러지가 된다.
약한 프로그래밍 언어(Weak Programming Language)란 더 느슨한 타이핑 규칙을 가지고 예측할 수 없거나 잘못된 결과를 생성하거나 런타임에 암시적 타이프 변환을 수행할 수 있다. --> JavaScript와 같은 동적언어
클러지(Kludge)는 IT에서 불일치 한 부품이나 요소, 일반적으로 제대로 작동하지 않는 서투른 구조로 잘못 설정된 시스템을 말한다.
예를 들어, 전략 패턴은 대부분의 현대 프로그래밍 언어에서 간단한 익명 함수로 구현될 수 있다.
비효율적인 솔루션
패턴은 이미 널리 사용되는 접근법을 체계화하기 때문에 많은 사람들에게 "도그마"로 여겨지고, 프로젝트 맥락에 상관없이 패턴의 모든 부분을 무지성으로 따라하려고 한다.
잘못된 사용
"망치만 있으면 모든 것이 못처럼 보인다."
이것은 패턴에 이제 막 익숙해진 많은 초보자들을 괴롭히는 문제이다. 패턴에 대해 배운 후, 그들은 더 간단한 코드로도 충분할 상황에서도 패턴을 적용하려고 노력한다.
패턴의 분류
디자인 패턴은 설계되는 전체 시스템에 대한 복잡성, 세부 수준 및 적용 가능성의 규모에 따라 다르다.
가장 기본적이고 낮은 수준의 패턴은 종종 idiom(관용구)라고 불리는데 이들은 보통 하나의 프로그래밍 언어에만 적용된다.
가장 보편적이고 높은 수준의 패턴은 architectural patterns(건축 패턴)이다. 개발자는 이러한 패턴을 대부분의 언어로 구현할 수 있다. 다른 패턴과 달리 이는 전체 어플리케이션 아키텍처를 설계하는 데 사용될 수 있다.
또한 모든 패턴은 의도 또는 목적에 따라 분류될 수 있다. 이 책은 세 가지 패턴의 주요 그룹을 다룬다.
-
Creational patterns은 기존 코드의 유연성과 재사용성을 증가시키는 객체 생성 메커니즘을 제공한다.
-
Structural patterns은 구조물을 유연하고 효율적으로 유지하면서 객체와 클래스를 더 큰 구조로 조립하는 방법을 설명한다.
-
Behavioral patterns은 효과적인 의사소통과 객체 간의 책임 할당을 담당한다.
참고사이트
