디자인 패턴이란?

디자인 패턴은 소프트웨어 디자인 과정에서 자주 발생하는 문제들에 대한 전형적인 해결책이다.

이는 코드에서 반복되는 디자인 문제들을 해결하기 위해 맞춤화할 수 있는 미리 만들어진 청사진(Blueprint)과 비슷하다.

 

표준화된 라이브러리들이나 함수들을 코드에 복사해 사용하는 것처럼 패턴들을 붙여 넣기 식으로 사용할 수는 없다. 패턴은 재사용할 수 있는 코드의 조각이 아니라 특정 문제를 해결하는 방식을 알려주는 일반적인 개념이다. 당신은 패턴의 세부 개념들을 적용하여 당신의 프로그램에 맞는 해결책을 구현할 수 있다.

 

패턴은 알고리즘과 자주 혼동이 되곤 한다. 왜냐하면 두 개념 모두 알려진 문제에 대한 일반적인 해결책을 설명하기 때문이다. 알고리즘은 어떤 목표를 달성하기 위해 따라야 할 명확한 일련의 절차를 정의하지만, 패턴은 해결책에 대한 더 상위 수준의 설명이다. 예를 들어 같은 패턴을 두 개의 다른 프로그램에 적용하면 두 프로그램의 코드는 다를 것이다.

 

알고리즘은 요리법에 비유할 수 있지만 패턴은 요리법이 아닌 청사진에 더 가깝다.

알고리즘과 요리법 둘 다 목표를 달성하기 위한 명확한 단계들이 제시되어 있다. 반면에 청사진은 결과와 기능들은 제시하나 구현 단계 및 순서는 사용자가 결정한다.

 

패턴은 무엇으로 구성되어 있나?

많은 상황에서 패턴을 재현할 수 있도록 대부분의 패턴을 매우 형식적으로 설명했다. 패턴 설명에 일반적으로 표시되는 세션들은 다음과 같다.

 

• 패턴의 의도 섹션에서는 문제와 해결책을 간략하게 설명한다.
• 동기 섹션에서는 문제와 패턴이 가능하게 하는 해결책을 추가 설명했다.
• 클래스의 구조 섹션에서는 패턴의 각 부분과 이러한 부분들이 어떻게 연관되어 있는지를 보여준다.
• 코드 예시 섹션에서는 여러 인기 있는 프로그래밍 언어들로 된 코드 예시를 제공하여 독자들이 패턴 뒤의 아이디어를 이해하기 쉽도록 했다.

일부 패턴 섹션에서는 패턴의 적용, 구현 단계 및 다른 패턴과의 관계와 같은 유용한 세부 정보들도 설명한다.

 

패턴의 역사

패턴(pattern)은 프랑스어 낱말 patron에서 온 것으로, 되풀이되는 사건이나 물체의 형태를 가리킨다. 그러면 누가 디자인 패턴을 발명했을까? 좋지만 정확하지 않은 질문이다. 디자인 패턴은 모호하고 복잡한 개념이 아니라 객체 지향 설계의 일반적인 문제들에 대한 일반적인 해결책이다. 같은 해결책이 다양한 프로젝트에서 계속해서 반복적으로 사용되면, 결국 누군가 그것에 대해 이름을 붙여 개념을 자세히 설명하게 된다. 기본적으로 디자인 패턴은 이렇게 발견되었다.

 

패턴이라는 개념은 『패턴 랭귀지: 도시 건축 시공』 (크리스토퍼 알렉산더)에서 처음으로 설명되었다. 이 책은 도시 환경을 설계하기 위한 '언어'를 설명하며, 이 언어의 단위가 패턴이다. 패턴으로 창문이 얼마나 높아야 하는지, 건물이 몇 층이어야 하는지, 근처 녹지의 면적이 얼마나 넓어야 되는지 등을 설명할 수 있다.

 

이 개념은 에릭 감마, 존 블리시디스, 랄프 존슨, 리처드 헬름이라는 4명의 작가에 의해 정리되었으며 1994년, 이들은 디자인 패턴:재사용성을 지닌 객체지향 소프트웨어의 핵심 요소라는 책을 발간하였고, 거기서 디자인 패턴의 개념을 프로그래밍에 적용하였다. 이 책은 다양한 객체 지향 디자인 관련 문제를 해결하는 23가지 패턴을 소개했으며 금방 베스트셀러가 되었다. 너무 긴 제목 때문에 사람들은 이 책을 '4인방(Gang of Four)이 쓴 책'이라고 부르기 시작했으며 곧 간단히 'GoF 책'으로 줄여 부르게 되었다.

 

그 이후로 수많은 다른 객체 지향 패턴이 발견되었다. '패턴 접근법'이 다른 프로그래밍 분야에서도 인기를 얻으면서 이제는 객체 지향 디자인 외부에도 많은 패턴이 존재하게 되었다.

 

왜 패턴을 배워야 하나요?

현실은 당신이 패턴에 대해 아무것도 알지 못해도 수년 동안 프로그래머로 일할 수 있다는 것이다. 실제로 많은 프로그래머가 패턴에 대한 아무런 지식 없이 업무를 수행한다. 또 자신도 모르는 사이에 일부 패턴들을 구련하고 있을 수도 있다. 그럼에도 왜 패턴을 배워야 하는지, 그 이유들을 정리해 보겠다.

 

• 디자인 패턴은 소프트웨어 디자인의 일반적인 문제들에 대한 시도되고 검증된 해결책들을 모은 것이다. 이러한 문제들을 다루지 않더라도 패턴을 알고 있으면 여전히 쓸모가 있는데, 그 이유는 패턴을 배우게 되면 객체 지향 디자인의 원칙들을 사용해 많은 종류의 문제를 해결하는 방법들을 배울 수 있기 때문이다.
• 디자인 패턴은 당신과 당신의 팀원들이 더 효율적으로 의사소통하는 데 사용할 수 있는 고통 언어를 정의한다. 예를 들어서 당신의 팀이 디자인 패턴을 이해하면 업무 처리 중 당신이 '그 문제를 위해서는 그냥 싱글턴을 사용하세요'라고 말하면 모두가 당신이 무엇을 뜻했는지 이해할 수 있을 거이며 싱글턴 패턴에 포함된 개념들은 설명할 필요도 없을 것입니다.

 

패턴에 대한 비판

많은 사람들이 디자인 패턴에 대해 비판했다. 이들이 주장하는 패턴을 사용하지 말아야 할 보편적인 이유에 대하여 알아보자

 

약한 프로그래밍 언어를 위한 클루지로 작동한다.

일반적으로 패턴의 필요성은 개발자가 추상화 수준이 부족한 프로그래밍 언어나 기술을 선택했을 때 발생한다. 이 경우 패턴은 약한 프로그래밍 언어에 필요한 초능력을 부여하는 클루지(문제의 어지럽고 임시변통의 그러나 효과적인 해결책)로 작동한다.

 

예를 들어  Strategy 패턴은 대부분의 최신 프로그래밍 언어에서 간단한 익명(람다) 함수로 구현할 수 있다.

 

비효율적인 해결책

패턴은 이미 널리 사용되는 문제 해결 방식의 체계화를 시도합니다. 많은 사람이 이렇게 통합된 패턴들을 도그마처럼 신봉하여 패턴을 프로젝트의 맥락에 따라 적용하지 않고 '문자 그대로' 구현한다.

 

부당한 사용

망치만 있으면 모든 것이 못처럼 보입니다.

 

많은 초보자는 패턴을 각 배운 후, 더 간단한 코드로도 문제 해결이 되는 상황에도 모든 곳에 패턴을 적용하려고 한다. 이것은 최근에 패턴에 익숙해진 많은 초보자를 괴롭히는 문제이다.

 

패턴의 분류

디자인 패턴은 복잡성, 상세도 및 설계 중인 전체 시스템에 대한 적용 범위에 따라 분류된다. 저는 도로 건설에 비유하는 걸 좋아한다. 교차로를 더 안전하게 만들기 위해 신호등을 설치하거나 보행자를 위한 지하도가 있는 전체 다층 인터체인지를 구축하는 작업에 비유할 수 있다.

 

가장 기본적인 하위 설계 패턴을 이디엄이라고 한다. 일반적인 이디엄은 단일 프로그래밍 언어에만 적용할 수 있다.

 

아키텍처 패턴은 상위 설계 패턴이며 가장 보편적으로 사용된다. 개발자들은 거의 모든 언어로 아키텍처 패턴들을 구현할 수 있으며 다른 패턴들과 달리 애플리케이션 전체의 구조(아키텍처)를 설계하는 데 사용할 수 있다.

 

또한 모든 패턴은 패턴의 의도 또는 목적에 따라 분류 할 수 있다.

 

• 생성 패턴은 기존 코드의 재활용과 유연성을 증가시키는 객체 생성 메커니즘들을 제공한다.
• 구조 패턴은 구조를 유연하고 효율적으로 유지하면서 객체와 클래스를 더 큰 구조로 조합하는 방법을 설명한다.
• 행동 패턴은 객체 간의 효과적인 의사소통과 책임 할당을 처리한다.

 

출처 

디자인 패턴들