0. 디자인 패턴, 왜 알아야 할까?

소프트웨어 공학과 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.
- 위키페디아 -

프로그래밍 이라는 분야에 대해서 공부를 했거나 관심이 있다면 한번 이상은 들어봤을 법한 이름이다.

단순히 정의를 간단히 되짚어 보면 디자인 패턴은 문제들을 해결하는데에 쓰이는 서술이나 템플릿 이라고 볼 수 있다.

 

그 종류는 수십가지가 넘으며 이 분야의 바이블이라 할 수 있는 「GoF 의 디자인 패턴」 이라는 책은

개발자라면 꼭 읽어봐야 할 책 으로 꼽힐만큼 중요한 책이지만 약 500 페이지의 분량과 내용 구성만 봐도

5분만에 덮어버리고 싶을만큼 극악무도한 책이다.

 

그래서 디자인 패턴이라는게 있다 정도만 알거나

혹은 배우더라도 이걸 어디에 쓰는건지 잘 모르는 경우가 있을 수 있다.

---

우선 객체지향 프로그래밍에 대해서 다시 생각해볼 필요가 있다.

실행 순서를 기반으로 하는 절차지향과는 달리 데이터와 함수들을 하나의 독립된 객체로 처리하는 것이다.

 

알다시피 여기에는 크게 4가지 요소가 존재한다.

• 추상화 : 기본이 되는 클래스를 기반으로 그 내용을 하위 클래스에서 구체화 시킨다.
• 캡슐화 : 필요한 정보만을 보여주어 정보의 은닉이 가능하다.
• 상속 : 상위 클래스의 기능을 물려받아 재사용성을 증가시킨다.
• 다형성 : 기능을 재정의(오버라이드)하거나 유연하게(오버로딩) 만들 수 있다.

여기서 디자인 패턴을 다시 정의해보면

디자인 패턴은 위 요소들을 극대화하여 만들어진 검증된 템플릿 이라고 말할 수 있을 것 같다.

---

그렇다면 이번에는 이 글의 제목인 꼭 디자인 패턴을 알아야만 하는가? 에 대한 대답이다.

답은 아니다. 하지만 알고 있으면 많은 시간과 노력을 단축할 수 있다.

 

디자인 패턴에 대해서 잘 모르는 상태로 어느정도 개발 경험을 해본 후 패턴에 대해서 공부하면

놀라는 경우가 생길 것이다. 오랜 시간 고민하고 노력하여 만든 코드가 이미 다 나와있기 때문이다.

(필자의 경우가 그렇다.)

 

또한 다른 개발자와 대화를 할때 ~에서 ~를 어떻게 하고 어쩌구 저쩌구 라고 설명하는 것 보다

~ 패턴으로 하면 좋을 것 같다 고 말하는게 훨씬 간단하고 직관적이다. (전문적이고 있어보이는건 덤이다.)

 

즉, 디자인 패턴을 알고있으면 위 정의와도 같이 어떠한 문제에 대한 해결책을 이미 알고 있는 것이며

더 나아가 코드를 효율적으로 설계하는데에 새로운 시야를 열어줄 것이라 장담한다.

 

물론 모든 디자인 패턴에 대해서 꿰고 있어야 할 필요도 없기 때문에

자주 쓰는것과 그 밖에 것들은 '아 이런게 있던거 같은데...' 라며 대충 기억만 하고 있어도 된다.

우리에겐 구글이라는 든든한 친구가 있기에 너무 부담가질 필요도 없다.

 

이 카테고리에선 자주 쓸만한 것들과 알고있으면 유용한 것들에 대해 몇가지만 소개해보려한다.