디자인 패턴이란?

디자인 패턴은 선배들의 경험이 담긴 문제 해결 방법입니다. 예로부터 건물을 지을 때는 사전 설계가 중요했습니다. 어떤 문제나 수정 사항이 발생했을 때, 하나하나 시행착오를 겪으면서 다시 짓기에는 시간과 비용이 많이 들기 때문입니다. 사람들은 같은 실수를 반복하지 않기 위해 자신들의 시행착오를 바탕으로 특정 상황에서 발생하는 문제 패턴을 발견하고 해결방안을 기록으로 남겼습니다. 이를 ‘디자인 패턴’이라고 부릅니다.

건축학에서 시작된 디자인 패턴은 코드로 소프트웨어를 구축한다는 점에서 소프트웨어 설계에도 동일하게 적용할 수 있습니다. 누군가‘가’ 겪은 문제가 누군가‘만’ 겪은 문제는 아니므로 동일한 문제를 먼저 경험한 선배들의 지식을 활용한다면 소프트웨어 설계의 효율을 추구할 수 있습니다.

아마 한 번쯤은 기성 라이브러리와 프레임워크를 사용해 본 적이 있을 것입니다. 그냥 가져다가 API에 맞춰서 코드를 짜고 컴파일하면 다른 사람이 만들어 놓은 방대한 분량의 코드를 그대로 활용할 수 있죠. 자바 API가 제공하는 네트워크, GUI, IO와 같은 수많은 기능을 생각해 보세요. 라이브러리와 프레임워크는 개발 모델 전반에 걸쳐서 많은 영향을 미칩니다. 언제든지 적절한 구성 요소를 선택해서 제자리에 넣기만 하면 되니까요. 하지만 그러한 라이브러리와 프레임워크가 더 이해하기 쉽고, 관리하기 쉬운 유연한 방법으로 애플리케이션의 구조를 만드는 데 도움을 주지는 못합니다. 라이브러리나 프레임워크가 도와주지 못하는 부분을 도와주는 것이 바로 디자인 패턴입니다.

일단 디자인 패턴을 완전히 익혀 두면 어떤 코드가 유연성 없이 엉망으로 꼬여 있는 스파게티 코드인지 금방 깨달을 수 있으며 그 코드를 수정할 때 패턴을 적용해서 코드를 개선할 수 있습니다.

디자인 패턴을 사용하면 어떤 장점이 있나요?

디자인패턴 간단하게 말하기.png

패턴으로 소통하면 일상어로 설명할 때보다 훨씬 효율적인 의사소통을 할 수 있습니다.

1. 서로 같은 패턴을 알고 있을 때의 위력은 정말 막강합니다.
다른 개발자나 같은 팀에 있는 사람과 패턴으로 의사소통하면 패턴 이름과 그 패턴에 담겨있는 모든 내용, 특성, 제약 조건 등을 함께 바로 이야기 할 수 있습니다.

2. 패턴을 사용하면 간단한 언어로 많은 얘기를 할 수 있습니다.
뭔가를 설명할 때 패턴을 사용하면 내가 생각하고 있는 디자인을 다른 개발자가 빠르고 정확하게 파악할 수 있습니다.

1 ~ 2번 장점의 예를 들면, "오리들의 다양한 행동을 전략 패턴으로 구현하고 있습니다"라고 얘기한다면 이는 오리의 행동들을 쉽게 확장하거나 변경할 수 있는 클래스들의 집합으로 캡슐화되어 있다 라는 사실을 간단하게 한 문장으로 설명할 수 있는 것이죠.

3. 패턴 수준에서 이야기하면 '디자인'에 더 오랫동안 집중할 수 있습니다.
디자인 회의 중에 구현과 관련된 자질구레한 내용 때문에 논점이 빗나가 본 경험이 있으신가요? 소프트웨어 시스템을 이야기할 때 패턴을 사용하면 객체와 클래스를 구현하는 것과 자질구레한 내용에 시간을 버릴 필요가 없어서 디자인 수준에서 초점을 맞출 수 있습니다.

4. 전문용어를 사용하면 개발팀의 능력을 극대화할 수 있습니다.
디자인 패턴 용어를 모든 팀원이 잘 알고 있다면 오해의 소지가 줄어 작업을 빠르게 진행할 수 있습니다.

5. 전문 용어는 신입 개발자에게 훌륭한 자극제가 됩니다.
신입 개발자는 경험이 풍부한 개발자를 우러러봅니다. 선배 개발자가 디자인 패턴을 사용하면 신입 개발자들에게는 디자인 패턴을 배울 동기가 부여됩니다.

어떤 경우에 패턴을 써야 할까요?

디자인을 할 때, 지금 디자인상의 문제에 적합하다는 확신이 든다면 패턴을 도입해야 합니다. 만약 더 간단한 해결책이 있다면 패턴을 적용하기 전에 그 해결책의 사용을 고려해 봐야 합니다. 언제 패턴을 적용할지를 올바르게 결정하려면 상당한 경험과 지식이 축적되어야 합니다.

만약 어떤 패턴을 써야 할지 잘 모르겠다면 문제 해결에 도움이 될 만한 패턴이 있는지 훑어봐야 합니다. 이런 경우에는 패턴 카탈로그의 용도와 적용 대상 부분을 살펴보면 좋습니다. 일단 괜찮은 패턴을 찾았다면 결과 부분을 보고 디자인의 나머지 부분에 미치는 영향이 어느 정도인지 확인해 봐야 합니다. 이 정도까지 했을 때 패턴을 써도 괜찮겠다 싶으면 그 패턴을 적용하면 되죠.

간단한 해결책으로 문제가 해결되는 데도 시스템의 어떤 부분이 변경될 거라고 예측되는 상황에는 디자인 패턴을 적용해야 합니다. 디자인에서 변경될 수 있는 부분이 있다면 패턴을 적용할 여지가 있습니다. 하지만 발생 가능성이 높은 실질적인 변경에 대비해서 패턴을 적용해야지, 가능성이 그리 높지 않은 가상적인 변경에 대비해서 패턴을 적용하는 일은 바람직하지 않습니다. 패턴 도입을 디자인 단계에서만 고려해야 하는 건 아닙니다. 나중에 리팩터링을 할 때도 패턴 도입을 고려할 수 있습니다.

원스톱으로 배우는 14가지 GoF 핵심 디자인 패턴과 9가지 객체지향 디자인 원칙!

『헤드 퍼스트 디자인 패턴』은 현장에서 자주 사용되는 옵저버, 어댑터, MVC 패턴 등 14가지 GoF 객체지향 패턴을 중점으로 패턴의 정의, 사용 시기, 사용처, 사용 이유, 즉시 디자인에 적용하는 방법을 알려드립니다! 이와 더불어 객체지향 프로그래밍에 광범위하게 적용할 수 있는 OCP, 할리우드 원칙 등 9가지 객체지향 디자인 원칙과 패턴으로 생각하는 방법도 알려드려요!