디자인 패턴의 등장 배경
개발자들은 개발을 하면서 프로그램의 유연성과 확장성과 관련된 비슷한 문제들을 마주하며, 이 문제들은 풀기 위해서 많은 시간이 소요된다. 만약 이 문제들에 해결책이 있다면 어떨까? 문제를 풀기 위한 시간을 줄일 수 있을 것이다. 이러한 생각에서 만들어진 것이 바로 소프트웨어 디자인 패턴이다.
디자인 패턴은 개발을 하면서 생길 수 있는 문제를 유형별로 나눠서 해결책을 제시한다. 즉, 디자인 패턴은 일종의 수학 공식 같은 역할을 한다. 다만 수학 문제가 개발의 확장성 유연성 문제가 되고 수학 공식은 디자인 패턴이 된다. 만약 우리가 근의 공식을 안다면 2차 함수 문제를 빠르게 풀 수 있지만 근의 공식을 모른다면 2차 함수 문제를 푸는데 시간이 걸린다. 디자인 패턴도 마찬가지로 디자인 패턴을 안다면 짧은 시간에 문제를 풀어낼 수 있지만 모른다면 많은 시간이 걸리게 된다.
이러한 디자인 패턴들을 정리해 나온 책이 바로 1994년에 나온 GoF(Gang of Four)이 쓴 Design Patterns: Elements of Reusable Object-Oriented Software 이며, 이 책은 프로그래밍 언어를 배운 사람이라면 누구나 한 번쯤을 들어봤을 책이다.
*이펙티브 자바 등 유명한 책들에서 여러 번 언급됐다.
디자인 패턴과 프로그래밍
많은 프로그래머들이 디자인 패턴을 중요하게 생각하는 이유는 바로 디자인 패턴을 통해 프로그램 설계에 대한 추상화를 할 수 있기 때문이다. 디자인 패턴은 우리가 프로그램을 객체 관점보다 높은 레벨에서 생각할 수 있도록 도와준다. 만약 너무 낮은 레벨에서 프로그램을 다루게 된다면 높은 레벨의 생각이 어려워지는 것과 같은 이치이다.
한 번 문제를 내보겠다. 아래와 같은 휴지통이 있다고 해보자. 휴지통을 휴지라는 단어 없이 다른 사람에게 묘사한다고 해보자 어떻게 하겠는가?
아마 다음과 같이 설명할 것이다.
휴지통 : 안에 얇고 부드러운 사각형 천이 여러개 들어 있는 통.
만약 휴지통이라는 고차원적(고레벨)인 단어를 안다면 이를 그냥 휴지통이라고 하면 되지만, 휴지통이라는 단어를 쓸 수 없다면 다음과 같이 장황하게 설명(낮은 레벨)을 해야 한다. 장황하게 설명하는 것은 이해하기 어렵다. 즉, 낮은 레벨로 설명하는 것은 장황하고 이해하기 어려워진다.
프로그램도 마찬가지이다. 프로그래밍 전문가들은 디자인 패턴을 장황하게 설명하지 않고 디자인 패턴 그 자체의 이름만을 말해서 프로그램설계의 복잡도를 줄인다. 전략 패턴, 옵저버 패턴 등 디자인 패턴 그 자체만을 말하면 장황하게 설명할 필요 없이 인식이 가능한 것이다. "프로그래머의 뇌" 책에서는 디자인 패턴을 사용하는 이유를 바로 사람들이 디자인 패턴을 Chunk(덩어리)로 인식해서라고 한다. 변수 선언이나 클래스 선언을 덩어리로 인식하는 것과 같이 디자인 패턴 또한 덩어리로 인식하게 되면, 장황한 코드를 이해하는데 시간을 획기적으로 줄일 수 있다.
디자인 패턴과 협업
디자인 패턴은 프로그래머들 사이에서 공유되는 패턴이다. 프로그래머들이 의사소통 할 때 양쪽 모두 디자인 패턴을 알고 있다면 간단한 단어로 복잡한 의사소통을 대체하는 것이 가능해진다. 의사소통을 간단한 단어로 대체하는 것이 가능해지면, 프로그래밍 구조 관점에서 프로그램에 대해 논의하는 것이 수월해진다. 더욱 높은 레벨에서 의사소통을 함으로써 더욱 쉽게 이해할 수 있게 된다.
