메뉴

디자인 pattern

2016-01-16 16:09:20

목차

Design pattern

소프트웨어 엔지니어링에서 디자인 패턴은 "주어진 컨텍스트내에서 발생할 수 있는 문제를 해결하기 위한 솔류션을 포함하고 있는 디자인"이다. 패턴은 프랑스어인 patron을 기 기원으로 하고 있는데, 어떤 구조물에서 찾아볼 수 있는 규칙적인 성질, 이벤트, 구조를 말한다. 즉 소프트웨어에서 디자인 패턴은 소프트웨어에서 찾아볼 수 있는 규칙적인 성질, 구조를 체계적으로 정리한 것이라 할 수 있다.

디자인 패턴은 "완성된 모습", "완성된 코드"를 포함하고 있지 않다. 다양한 상황에서 사용할 수 있도록 정리된 템플릿에 가깝다. 범용적으로 사용할 수 있도록 정리된 템플릿 중 내가 가진 문제 해결에 적합한 템플릿을 가져와서 "내 환경에 맞게 수정"해서 사용하는 것이다. 일반적인 문제를 해결하는데 사용 할 수 있는 공식화된 모범 사례(Best Practices)인 셈이다.

개발 과정에서 보자면 디자인 패턴은 "프로그래밍 패러다임"과 구체적인 알고리즘 중간에서 이들을 잇는 "컴퓨터 프로그래밍에 대한 구조화된 접근 방식"으로 볼 수 있다.

피턴은 1977년 Christopher Alexander의 건축 분야에서 시작됐다. 소프트웨어 공학이 발전하면서 소프트웨어 구조를 체계화 해야겠다는 요구가 증가했고, 건축 분야에서의 패턴이 문제해결이 될 수 있다고 생각했다. 1987년 Kent Beck과 Ward Cunningham은 프로그래밍에서 패턴을 적용하는 아이디어를 실험하기 시작했으며 그해 OOPSLA 회의에서 결과물을 발표했다.

디자인 패턴이 본격적으로 인기를 얻은 건 1994년 GoF로 약칭되는 "Design Patterns: Elements of Resuable Object-Oriented Software"가 출판되면서 부터일 것이다. 같은 해 첫번째 Pattern Languages of Programming Conference가 열렸고, 1995년 디자인 패턴의 문서화를 위해 "Portland Pattern Repository"가 설립된다.

 GoF

지금은 수십가지의 패턴이 있으며, 이렇게 패턴기반으로 소프트웨어 개발을 접근하는 것은 여러 프로그래밍 분야에서 인기를 얻고 있다. 최근에 클라우드가 본격적으로 사용되면서, "모범 사례"의 형식으로 클라우드 패턴이 적용되고 있다.

패턴을 배워야 하는가 ?

진실을 말씀드리자면 패턴을 알지 못해도 프로그래머로 일 할 수 있습니다. 실제로 많은 사람이 그렇게 하고 있으며, 이런 경우에도 자신도 모르는 사이에 일부 패턴을 구현하는 경우가 많습니다. 이런 개발자가 패턴 문서를 읽으면, "어 이거 내가 하고 있던 방법인데"라는 생각을 하게 됩니다. 그렇다면 왜 패턴을 배워야 할까 ?

  1. 디자인 패턴은 일반적인 문제를 해결하기 위한 그동안의 노력, 테스트, 경험을 구체화한 툴 킷이다. 지금 당장 모든 패턴을 사용할 필요가 없더라도, 패턴을 학습하는 것만으로 문제를 해결하는 방법의 인사이트를 얻을 수 있다.
  2. 디자인 패턴은 조직에서의 의사 소통에 도움을 준다. "싱글톤을 사용하세요"라고 한마디 해주는 것으로 모두가 당신의 제안뒤에 숨겨진 아이디어를 이해 할 수 있다.

비판

손에 망치가 있으면 모든게 못으로 보인다.

이 문제는 이제 막 패턴을 배운 초보자들에게서 쉽게 발생 할 수 있는 문제다. 간단한 코드로 문제 없는 상황에서 모든 곳에 패턴을 적용하려고하지 말자. 패턴은 KISS(Keep it small and simple)원칙과 충돌할 수 있는 부분이 있으니, (모든 툴 들이 그렇지만)효과적으로 사용해야 한다.

패턴의 분류

패턴은 "창조적 디자인 패턴", "구조적 디자인 패턴", "행동적 디자인 패턴"의 세 가지 범주로 분류한다.

각 분류에 따른 디자인 패턴 목록

창조적 디자인 패턴

구조 설계 패턴

행동적 디자인 패턴

참고