Design Pattern

[ dizain pætərn ]

CHAPTER 0 디자인 패턴

0.1 패턴

패턴이 디자인 패턴이라는 단어를 처음 접했을 때 대부분의 사람들은 패션이나 디자인 분야 관련 내용이라고 생각합니다. 그러나 개발 분야에서 패턴이라는 말은 많은 사람이 겪은 문제점과 해결 방법을 정리해둔 것을 말합니다.

0.1.1 유래

패턴이란 사전적인 의미로 일정한 형태나 양식 또는 유형으로 반복되는 것을 말합니다. 이처럼 반복되는 패턴의 원리에 대한 개념을 공학적인 측면에서 도입한 것이 디자인 패턴의 시작입니다.

공학 분야에서 처음으로 패턴의 개념을 도입한 분야는 건축공학입니다. 대표적인 건축가인 크리스토퍼 알렉산더(Christopher Alexander)는 패턴의 개념을 건축 공학에 적용해 반복적이고 복잡한 일을 해결하기 시작했습니다.

0.1.2 창발

패턴은 발명하는 것이 아니라 발견하는 것입니다. 처음 건축학에서 도입된 패턴도 발명이 아닌 발견에서 시작됐습니다.

실생활에서 어떤 것을 ‘발견’하기 위해서는 수많은 관찰이 필요하며, 지속적인 관찰을 통해 특정한 패턴을 발견하게 됩니다. 이러한 발견을 창발(emergence)이라고 합니다.

0.1.3 비슷한 것

발견된 패턴을 면밀히 살펴보면 서로 비슷한 부분이 많다는 것을 알 수 있습니다. 즉 특정한 문제를 해결하는 과정이나 방법 등이 유사합니다.

패턴은 문제를 해결하는 과정을 일반화한 것이라고 할 수 있으며, 하나의 패턴이 또 다른 패턴에 중복적으로 사용되는 경우도 있습니다.

디자인 패턴을 구별하는 기준은 각각의 패턴이 어떤 관심사를 가지고 문제를 해결하려는가 하는 것입니다. 패턴은 의도와 목적에 따라 달라지므로 적절한 패턴을 적용하기 위해서는 의도와 목적을 잘 파악하는 것이 중요합니다.

0.2 소프트웨어 공학

이러한 패턴의 원리는 소프트웨어 공학 분야에도 도입되기 시작했습니다. 소프트웨어적인 문제를 코드로 구현할 때 적용했던 해결 방법을 패턴화하여 정리한 것입니다.

0.2.1 객체지향

처음으로 소프트웨어 공학에 도입된 부분은 객체지향 개발입니다. 객체지향 개발은 1980년대부터 존재했던 소프트웨어 개발 방법론입니다.

최근 들어 객체지향 코드를 작성할 수 있는 언어가 늘어났습니다. 객체지향 언어의 종류로는 전형적인 스몰토크, C++, 자바 외에 웹 개발 언어인 PHP가 있습니다.

객체지향 기반으로 개발할 때 가장 어려운 부분은 각각의 코드를 재사용 가능한 형태의 코드로 작성하는 것입니다.

0.2.2 패턴 발견

객체지향은 큰 프로젝트 개발과 유지 보수를 보다 쉽게 하기 위해 도입된 개발 방법론입니다. 최근 프로그램들이 대형화, 분업화되면서 절차지향 개발 방법론에서 객체지향 개발 방법론으로 빠르게 이동하고 있습니다. 디자인 패턴은 객체지향 개발법이 인기를 얻으면서 함께 주목 받았습니다.

많은 프로그래머가 소프트웨어 개발 분야에서 특정 문제를 유사한 유형으로 해결한다는 것을 알게 됐고, 이에 해결 과정에서 발견된 방법들을 패턴화하여 규정하게 됐습니다. 패턴은 객체지향 구현 문제를 해결하기 위해 도입됐으며, 해결 방법을 재사용하는 것이라고 볼 수 있습니다.

0.2.3 해결책

객체지향 개발에서 디자인 패턴이 해결하는 주요 문제는 객체 간 관계와 소통 처리 부분입니다.

디자인 패턴은 객체지향 문제를 해결하기 위한 일련 of 코드 스타일입니다. 따라서 디자인 패턴을 적용하기 위해서는 객체 지향적인 코드를 작성할 수 있는 프로그래밍 언어가 필요합니다.

최신 PHP 언어에는 객체지향 코드를 개발하기 위한 여러 가지 OOP 기술이 포함돼 있습니다. 많은 PHP 웹 프레임워크가 객체지향, 디자인 패턴을 이용해 개발되는 추세입니다.

0.3 설계 원칙

디자인 패턴 외에도 객체지향 코드 개발 시 가급적 지켜야 할 원칙이 있습니다. 그 원칙의 앞자리를 모아서 SOLID라고 부르기도 합니다.

• 단일 책임의 원칙 (Single responsibility principle, SRP)
• 개방 폐쇄 원칙 (Open/closed principle, OCP)
• 리스코프 치환 원칙 (Liskov substitution principle, LSP)

• 인터페이스 분리의 원칙 (Interface segregation principle, ISP)

• 의존 관계 역전의 원칙 (Dependency inversion principle, DIP)

이 원칙들은 객체지향 코드를 작성하는 데 도움을 주지만, 시스템을 고려하지 않은 원칙을 적용할 경우 불필요한 일이 발생할 수도 있습니다. 따라서 각각의 원칙들은 코드의 목적에 맞게 적재적소에 적용하여 사용해야 합니다.

0.4 GoF

디자인 패턴을 이야기하면서 자주 듣는 말이 GoF(Gang of Four)라는 단어입니다. GoF는 에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)의 저서인 『GoF의 디자인 패턴』(피어슨에듀케이션코리아, 2007)을 가리키는 용어입니다. 즉 처음으로 소프트웨어 공학에서 사용되는 패턴을 정리한 사람들의 별칭이라고 할 수 있습니다.

0.4.1 패턴 카탈로그

디자인 패턴은 갑자기 생겨난 방식이 아니며, 이미 일상적인 개발 작업 속에서 자연스럽게 사용하고 있습니다. 어떻게 보면 새롭다는 생각도 들지 않을 것입니다.

GoF는 객체지향 분야의 문제점을 분석해 24개 패턴으로 분류했습니다. 즉 GoF는 기존 객체지향 설계 시 발생했던 문제를 카탈로그화하여 패턴으로 정리한 것입니다.

카탈로그화된 패턴은 시스템의 유지 보수 문서를 작성할 때 매우 유용합니다. 또 객체 간 상호작용이나 설계 의도 등도 쉽게 확인할 수 있습니다.

0.4.2 통일성

협업으로 대규모 프로젝트를 진행할 때 중요한 요소는 통일된 개발 방식을 공유하는 것입니다. 서로 개발하는 방식에 차이가 있을 경우, 최종 결과물로 통합하는 과정이 쉽지 않습니다.

PHP는 최근 코드의 가독성을 향상시키기 위해 PSR 코딩 스타일을 정의했습니다. 하지만 코딩 스타일만으로 통일된 개발을 진행하기에는 다소 부족합니다.

디자인 패턴은 개발 방법을 정의함으로써 보다 통일화된 좋은 코드를 작성할 수 있습니다. 또한 디자인 패턴은 개발자가 자신의 코드를 작성하고 다른 사람과 소통하는 데 좋은 코드 가이드입니다.

0.4.3 실체화

실체화(reification)는 ‘실제로 만든다’는 의미입니다. 그러나 실체화가 구현(implementation)을 의미하지는 않습니다. 실체화는 코드가 아니라 디자인을 말하기 때문입니다.

구조만으로 패턴을 파악하는 것은 불가능하며 패턴을 파악하려면 의도를 알아야 합니다. 이에 어떤 문제를 해결하기 위해 2개 이상의 패턴을 혼합하여 사용하는 경우가 많습니다.

0.5 패턴의 요소

24개로 분리된 디자인 패턴은 공통된 4가지 요소를 가집니다. 이 책에서는 24가지 패턴을 설명합니다.

• 이름 (pattern name)
• 문제 (problem)
• 해법 (solution)
• 결과 (consequence)

0.5.1 이름

24종류의 디자인 패턴은 각각 고유의 이름을 갖고 있습니다. 처음에는 패턴 이름이 정해지지 않았으나, 시간이 흘러 이를 정리하면서 각각의 패턴에 대한 명칭들이 생겨났습니다. 패턴의 고유한 이름을 사용하는 것은 다양한 개발자와 패턴을 응용하여 소통하는 데 매우 중요합니다.

패턴 이름을 통해 패턴의 용도를 직관적으로 이해할 수 있습니다. 코드 패턴의 스타일이나 해결하려는 용도에 따라 패턴의 이름을 정합니다.

패턴 이름이 가진 본래의 뜻과 연계하여 생각한다면 좀 더 쉽게 이해할 수 있습니다.

0.5.2 문제

각 패턴은 해결하고자 하는 문제(problem)를 갖고 있습니다. 그리고 이러한 문제들은 패턴 적용을 고려해야 하는 시점을 암시합니다.

코드에서 해결할 문제점을 발견한 후 그와 관련된 여러 배경을 먼저 정리합니다. 그리고 이러한 문제점을 해결할 수 있는 다양한 적용 사례를 찾아봅니다.

0.5.3 해법

문제점을 인식했다면 해결 방법을 찾아야 합니다. 이를 위해 객체 요소 간 관계를 정리하고 패턴은 객체들을 추상화하는 과정을 거칩니다. 또한 해결을 위한 객체를 나열합니다.

0.5.4 결과

디자인 패턴은 알려진 문제점들을 해결하는 데 효과적입니다. 하지만 디자인 패턴을 적용한다고 해서 모든 문제를 완벽하게 제거할 수는 없습니다. 24개의 디자인 패턴은 다양한 문제를 해결할 수 있는 선배 개발자의 경험에서 나온 것입니다.

모든 코드에서 디자인 패턴이 유용하다고 볼 수는 없습니다. 분명 개선되지 않은 부분도 있습니다. 패턴은 매우 유용하지만 꼭 필요한 경우를 생각해서 적절히 분배하여 사용해야 합니다.

0.6 유지 보수

디자인 패턴은 소프트웨어의 유지 보수성을 개선합니다.