디자인 패턴에 대한 학습에 앞서 객체지향적인 소프트웨어 설계를 위한 5가지 원칙에 대해 알아보자. 
앞으로 소개할 5가지의 원칙보다 가장 우선시 되는 원칙은 "고객의 요구사항 만족의 원칙" 일 것이다.
다른 모든 원칙은들은 이 원칙에 의해 조정되고 필요할 때는 무시될 수 있다. 

소프트웨어 설계를 하다보면 어떻게 설계하는 것이 더 좋을까? 는 의문이 점점 더 짙어질 것이다.
이때 5가지 원칙을 지침삼아 결정하도록 하자...

   확장에는 열려있고, 변경에는 닫혀있도록 설계하라는 원칙이다. 
    > 변하는 사항들을 잘 캐치하여 이러한 부분들에 대한 확장점을 고려하여 설계를 하되, 명시적으로 제공하지 않는
      인터페이스를 통해 클래스가 변경되지 않도록 반드시 필요한 인터페이스만 노출하여 잘 캡슐화 하라는 의미이다. 

 수퍼클래스가 사용된 자리를 서브클래스로 대체하여도 잘 작동해야 한다는 원칙이다. 
    > 객체지향 언어의 상속과 인터페이스 메커니즘이 이를 잘 지원하고 있다. 

   구체적인 것이 아닌 추상적인 것에 의존하게 하라는 원칙이다. 
    > 추상적인 것에 의존하게 되면 LSP에 따라 구현체를 교체할 수있으며 그만큼의 유연성을 얻을 수 있다. 

   하나의 일반적인 인터페이스 보다는 다수의 구체적인 인터페이스를 사용하라는 원칙이다.    
    > 인터페이스를 세부적으로 분리하면 다양한 인터페이스 조합을 갖는 유연한 클래스를 사용할 수 있기 때문이다. 

   하나의 클래스는 타당한 하나의 책임만을 담당해야 한다는 원칙이다.
    > 클래스가 방대해져서 복잡해지는 것을 막기 위해 오직 한가지 책임에 전념하라는 원칙이다. 다양한 역할을 하는 하나의
      클래스 보다는 서로 다른 역할을 하는 여러 클래스를 선호하라는 의미이다.  

알고리즘을 캡슐화하여 어떻게 유연하게 알고리즘에 변경을 적용할 수 있을까에 대한 고민이 "행동" 카테고리의 패턴들이다.
클래스들(객체들) 간에 어떻게 구조를 형성하여 특정 요구사항에 유용한 구조를 얻을 수 있을까에 대한 고민이 "구조"  카테고리의 패턴들이다. 

클래스(객체)들을  생성하는 방식을 어떻게 캡슐화하여 유연성을 얻을까에 대한 고민이 "생성" 카테고리의 패턴들이다. 

디자인 패턴 소개
옵저버 패턴
데코레이터 패턴
팩토리 패턴
싱글턴 패턴
커맨드 패턴
어댑터 패턴과 퍼사드 패턴
템플릿 메소드 패턴
이터레이터와 컴포짓 패턴
스테이트 패턴
프록시 패턴
컴파운드 패턴
...

대학교 입학후 프로그램을 시작하고 한창 자신감이 쌓여 가던 대학교 3학년 시절...
프로그래밍 분야에서 한발 더 나아가고 싶은 맘에 "디자인 패턴" 에 대해 공부했던 때가 생각난다. 
사실 그 당시에는 디자인 패턴이라는 멋드러진 이름에 매료되어 "어떻게 요구사항을 잘 만족시킬까?"
보다는 "어떻게 디자인 패턴을 적용하여 구조를 이쁘게 만들까?" 라는 생각에 사로잡혀 있었다. 
인터페이스와 구현클래스를 조합하기에 따라 특정 상황(요구사항이 바뀌는 상황)에서 코드에 대한 수정을 
최소화 한채 구조를 변경할 수 있도록 하는 패턴들이 어찌나 대단해 보였는지...
(이해하기 힘든 클래스 다이어그램 때문에 더 대단해 보였다.)

그 시절에 비해 상대적으로 많은 시간(5년)이 흘렀지만 실무 개발을 시작한지는 이제 갓 1년 4개월....정도 
얼마나 실력이 향상 되었겠느냐마는...소프트웨어를 바라보는 시야는 그때에 비하면 크게 성장했다고 생각한다. 

"Head First Design Pattern" 을 교재로 사내 스터디를 시작했다. 첫장을 소개하는 발표자의 음성을 들으면서 문득
예전일이 생각났다.  디자인 패턴에 대한 글을 작성해보려다가 기본원칙 몇개와 책에 있는 패턴을 설명하는 글을 정리해서
올리다가 중간에 그만두었었던 때가 말이다. 그 때는 경험이 결핍된 지식으로는 어쩌면 당연한 결과인 것이다. 

그때를 떠올리며 이제는 내 생각으로 디자인 패턴에 대해 설명할 수 있지 않을까? 는 생각이 들었다. 
시간이 흐르면 많은 생각들이 또 변하겠지만 중간 점검으로는 적절한 때인듯 하다.

디자인 패턴을 구성하고 있는 패턴들에 대해 알아보기 앞서 디자인 패턴이란 무엇인지 알아보는 것은 당연한 일!!
소프트웨어를 하나 둘 개발하며 경험을 쌓다보면 늘 모든 일에서 그렇듯이 소프트웨어 개발에 있어서의 반복적으로
등장하는 상황이 발생하기 시작한다. 누구나 한 분야의 일에 대해 여러번의 경험을 반복하면 효율적으로 그일을 처리하는 Know-how가 쌓이기 마련이다. 소프트웨어 개발에 있어서 그러한 Know-how 중 Design 즉 설계에 있어서의 노하우를
디자인 패턴이라고 한다.
덧붙히자면 소프웨어 개발은 고객과 대화를 통해 요구사항을 추출해내고, 해당 분야에 대한 정보수집을 토대로 분석과정을
거쳐 설계에 이르고 실제 구현을 하게 된다. 이런 소프트웨어 모든 각 단계에 대한 노하우 즉 패턴이 존재한다.
(하지만 노하우 전달이 어려울뿐..) 요구사항 수집 패턴, 정보수집 패턴, 분석패턴, 설계패턴, 구현패턴 갖가지 패턴들이
존재할 수 있으며 디자인 패턴은 설계 단계에 있어서의 패턴에 특별히 주목하는 것이다. 

물론 이 디자인 패턴들은 먼저 소프트웨어 개발을 지긋이 했던 선배들 (GOF 선배들이라고 들어봤나?)이 경험을 통해
이름을 붙이고 알기쉽게 분류를 해놓았다. 개개의 노하우에 이름을 붙히고 언제 사용하면, 무엇이 좋은가에 대한 것을
기준으로 분류를 해놓아 책으로 엮은 것이 그 유명한 "GOF(Gang Of Four)의 디자인 패턴" 이다.
디자인 이름만 이야기해도 뭔가 뽀대가 나지만, 알맹이 없는 어중이 떠중이가 되고 싶지 않다면 적어도 하나의 패턴에 대해
이야기 할때는 "패턴의 이름", "패턴을 적용할 상황", "적용시 장점과 단점" 까지는 함께 이해하는 것이 좋으리라.... 

초보 운전자에게 베스트 드라이버께서 운전 노하우를 요목조목 설명해주면 어떻겠는가? 디자인 패턴은 소프트웨어 개발 중 
발생할 수 있는 여러 문제상황 속에서 검증된 해결책이다.  적어도 비슷한 상황속에서 이 패턴을 사용하면 더 적은 노력으로
원하고자 하는 답을 얻을 수 있다는 것이다.  하지만 각양각색의 상황 속에 완전히 일치하는 해결책이란 존재하지 않는다.
자신의 상황에 맞게 패턴을 변형해서 적용해야 하는 경우가 더 많을 것이다. 
책에서 자주 언급되는 디자인 패턴 적용의 장점 중 하나는 의사소통 비용의 감소이다. 디자인 패턴에 대해 잘 알고 있는
개발자 간에 대화시 패턴의 이름은 그 어떤 구구절절한 설명보다도 간단 명료하게 전달 될 것이다. 하지만 디자인 패턴을
잘 모르는 개발자가 있다면? ...

노하우란 경험을 통해서만 습득할 수 있는 것이다. 개발 경험이 부족한 초급 개발자들이 디자인 패턴을 이해하기 어려워하는
것은 당연한 일이다.  내가 예전에 그랬듯이 소프트웨어에 어떤 디자인 패턴을 적용할까 라는 고민은 잘못된 고민이다.
소프트웨어에 발생하는 이 문제를 해결하기에 이 패턴을 사용하면 이러이러한 장점이 생길 것 같은데...라는 자세가 옳다고
생각한다.  디자인 패턴은 목적이 아니라 다만 최선의 답을 위한 해결책 중 하나의 선택안이라는 것을 명심하길 바란다.