주의: 패턴 중독

프로젝트 전반에 걸쳐 불필요하게 패턴으로 도배하는 것은 엔지니어링 관점에서 도가 지나친 것입니다. 디자인 패턴들은 마술이 아니며, 솔루션이 좋은 디자인이라고 자동적으로 보장해 주지도 않습니다. 디자인 패턴들은 단지 되풀이되는 문제들에 대한 재사용 가능한 솔루션들입니다. 다른 사람들이 그것을 발견하고 문서화해옴으로써 우리가 이미 발명된 바퀴를 찾고 있음을 깨닫게 해줍니다. 문제가 발생할 때 이러한 솔루션으로 해결될 수 있는 문제를 가려내고, 디자인 패턴을 적절하게 적용하는 것이 우리가 할 일입니다. 디자인 패턴에 대한 지식을 과시하려는 여러분의 욕구가 실용주의적인 시각을 가리지 않도록 하십시오. 여러분의 시야를 효과적인 비즈니스 솔루션을 제공하는 시스템을 설계하는 데 초점을 맞추고, 패턴은 각 패턴이 언급하는 문제를 해결하는 데 사용하십시오.1

패턴과 이디엄

패턴에 대해 본격적으로 살펴보기에 앞서 패턴(pattern)과 이디엄(idiom)을 비교해 보기로 하자. 디자인 패턴을 매우 일상적으로 사용하게 되면 이는 패턴이 아니라 이디엄이다. 이런 상황에서는 패턴이 특별한 무엇이 아닌 '이미 그렇게 되어 있는 것'일 뿐이다. 어떤 사람들은 패턴은 정형적인 방식으로 표현되어 있는 반면 이디엄은 그렇지 않다는 식으로 패턴과 이디엄을 구분하기도 하지만, 나는 이와 같은 정의를 따르지 않는다. 이디엄은 일상적으로 사용하게 된 패턴이다.
상속은 패턴이 이디엄으로 진화해 간 훌륭한 예이다. 1980년대 초 C 언어가 왕이었을 무렵 상속은 하나의 디자인 패턴이었다. 실제 C에서 'extends' 관계를 사용하는 여러 예들을 볼 수 잇다. 구체적인 예를 하나 들자면 malloc()의 표준 구현은 헤더(부모 클래스)를 사용하는데, 이 헤더는 확장(extends)되어 새로운 구조체(자식 클래스)를 생성할 수 있고, 자식 클래스는 부모 클래스의 free() 메소드를 상속하게 된다.
추상 함수 역시 상속 패턴의 일부였다. C에서 다른 목적을 위해 다르게 초기화된 함수 포인터의 테이블을 넘기는 것은 흔한 일이었다. 그리고 이는 C++가 abstract 메소드와 인터페이스 상속을 구현하는 방식과 같지만 C 세계에서는 이를 지칭하는 이름이 없었다.
상속은 C 언어에 내장되어 있지 않았으며, 대부분의 C 프로그래머들은 상속을 이용하여 프로그래밍하지 않았다. 그러므로 상속은 프로그래밍 이디엄이 아닌 패턴이었다. C에서의 상속은 비슷한 류의 문제를 해결할 때 많은 프로그램에서 발견되는 방법이었지만, 초중급 수준의 C 프로그래머들이 이용하는 방법은 아니었다. 요즘은 상속과 인터페이스 같은 기능이 많은 언어에 내장되어 있다. 이들은 이디엄이 된 것이다.2

참고문헌

  • 소프트웨어 아키텍트가 알아야 할 97가지 / Richard Monson-Haefel 저 / Eva Study 역 / 지앤선(志&嬋) / 2011년 04월 14일 / 원제 : 97 Things Every Software Architect Should Know
  • 실전 코드로 배우는 실용주의 디자인 패턴 / Allen Holub 저 / 송치형 편역 / 지앤선(志&嬋) / 2006년 07월 19일 발행 / 원제 : Holub on Patterns : Learning Design Patterns by Looking at Code

주석

  1. 소프트웨어 아키텍트가 알아야 할 97가지. 110쪽. 패턴 중독, Chad LaVigne. 

  2. 실전 코드로 배우는 실용주의 디자인 패턴. 22쪽.