참고: Head First Design Patterns
개요
지금까지 여러가지 디자인 패턴들의 정의와 특징, 그 활용 방법들에 대해 살펴보았다. 그러나, 아직까지 디자인 패턴이란 것이 무엇인지에 대한 정의는 한 번도 설명하지 않았다. 따라서, 이번엔 디자인 패턴 그 자체에 대해 이야기해보자.
정의
디자인 패턴은 아래와 같이 정의한다.
A Pattern is a solution to a problem in a context
패턴이란 어떤 맥락의 문제에 대한 해결책이다.
다소 직관적이지 못한 정의같다. 조금 더 상세하게 풀어보자면 다음과 같다.
- 맥락(Context): 패턴이 적용되는 상황을 의미한다. 그 중에서도 반복적으로 발생하는 상황.
- 문제(Problem): 위 상황에서의 목적 혹은 목표를 의미한다.
- 해결책(Solution): 목표를 위해 적용할 패턴을 의미한다.
결국 디자인 패턴은 반복되는 문제를 해결하기 위해 고안된 일종의 메뉴얼이라고 생각할 수 있겠다. 이 반복되는 문제의 종류에 따라 디자인 패턴을 분류할 수 있다.
디자인 패턴의 분류
디자인 패턴은 크게 아래의 3가지 카테고리로 분류할 수 있다.
- Creational(생성) 패턴: 객체와 그 객체를 인스턴스화 해야 하는 클라이언트 사이의 결합을 해제해주는 역할을 한다.
- Behavioral(행동) 패턴: 클래스들과 객체들의 상호작용과 책임 배분에 관련된 디자인 패턴들이다.
- Structural(구조) 패턴: 클래스 혹은 객체를 더 큰 구조에 구성할 수 있도록 해준다.
지금까지 배운 패턴들과 후에 다룰 몇가지 패턴들을 위 카테고리에 분류해보자면 다음과 같다.
또한, 주로 다루는 부분이 클래스인지 객체인지에 따라 나뉘기도 한다.
- Class(클래스) 패턴: 클래스들 사이의 관계(상속, 구현 등)을 묘사한다.
- Object(객체) 패턴: 객체들 간의 관계를 묘사한다. 주로 구성을 이용한다. 따라서, 객체 사이의 관계가 런타임에 생기며 이로 인해 동적이고 유연한 관계를 가진다.
그래서 언제 적용해야 하는가?
Keep it Simple!
지금까지 여러 디자인 패턴과 이들이 어떻게 적용되는지를 살펴보았지만, 디자인 패턴의 진정한 효과는 적재적소에 활용되었을 때 발휘된다. 때로는 동일한 문제를 디자인 패턴의 적용과, 단순한 코드 수정의 두 가지 방법이 있는 경우가 있다. 이런 경우, 디자인 패턴의 적용이 반드시 정답이 될 순 없다. 때로는 단순한 해결책이 오히려 객체지향을 해치지 않고 문제를 해결해줄 수도 있다.
디자인 패턴의 남용은 해롭다!
물론 맞닥뜨린 어떤 문제에 대해 특정 디자인 패턴이 해결책이 될 것이 보인다면, 당연히 수많은 선대 개발자들에 의해 검증된 해당 디자인 패턴이 매력적으로 보일 것이다.
그러나, 디자인 패턴은 종종 새로운 객체들과 클래스를 정의하도록 한다. 이러한 단점이 반복된다면 결과적으로 프로그램의 복잡도만 높아지고 비효율적인 프로그램이 될 수 있다.
또한, 무리하게 디자인 패턴을 적용하려다가 오히려 문제가 더 꼬일 수 있다. 때론 "쉬운 해결책 놔두고 굳이 이 디자인 패턴을 적용해야 하나?" 하는 의문이 들 수도 있다.
- 그럴 땐 그 생각이 정답이다!
디자인 패턴에 너무 집착하지 말자. 쉬운 길이 최선이 아니라는 뜻은 아니다.
