아는 게 힘 이라는 말도 있듯이, 디자인 패턴을 알아두면 피가 되고 살이 될 것입니다. 하지만 절대로 간과할 수 없는 사실이 있습니다. 이렇게 복잡하고 까다로운 이론을 아무리 많이 알고 있다고 해도 경험과 연습 없이는 별로 도움이 되질 못합니다.
패턴 중독을 피하고 패턴을 잘 적용하기 위해 도움이 될 만한 몇 가지를 정리해 봤습니다. 패턴으로 생각하는 힘을 가지게 된다면, 어떤 디자인을 봤을 때 패턴 적용 여부를 결정할 수 있는 안목을 가질 수 있게 됩니다.
디자인을 할 때 무엇보다도 중요한 원칙은 ‘최대한 단순한 방법으로 문제 해결하기’입니다. “이 문제에 어떻게 패턴을 적용할 수 있을까?”가 아니라, “어떻게 하면 단순하게 해결할 수 있을까?”에 초점을 맞춰야 합니다.
패턴을 사용하지 않고 문제를 해결한다고 해서 훌륭한 개발자로 인정을 받지 못하는 건 절대 아닙니다. 정말 단순하게 잘 만들 수 있다면, 다른 개발자들도 당신의 능력을 인정하고 존경할 것입니다. 가장 단순하고 유연한 디자인을 만들 때 패턴이 있어야 한다면 그때 패턴을 적용하면 됩니다.
패턴은 반복적으로 발생하는 문제의 일반적인 해결책입니다. 그리고 수많은 개발자가 오랫동안 검증한 해결책이라는 장점도 있습니다. 일단 패턴이 필요하다는 결론을 내리면 다른 개발자들도 비슷한 문제를 겪었고, 비슷한 기법을 적용해서 그 문제를 해결했다고 생각하면 마음이 편해집니다.
하지만 패턴이 만병통치약은 아닙니다. 그냥 패턴을 넣고 컴파일한다고 해서 기적같이 문제가 해결되진 않으니까요. 패턴을 사용할 때는 그 패턴이 설계한 디자인에 미칠 영향과 결과를 주의 깊게 생각해 봐야 합니다.
어떤 경우에 패턴을 써야 할까요? 디자인을 할 때, 지금 디자인상의 문제에 적합하다는 확신이 든다면 패턴을 도입해야 합니다. 만약 더 간단한 해결책이 있다면 패턴을 적용하기 전에 그 해결책의 사용을 고려해 봐야 합니다. 언제 패턴을 적용할지를 올바르게 결정하려면 상당한 경험과 지식이 축척되어야 합니다. 일단 간단한 해결책만으로는 부족하다고 확신을 가지면 해결해야 할 문제와 제약조건을 종합적으로 고려해 봐야 합니다. 그래야만 그 문제를 해결하는 데 쓸 수 있는 패턴을 정확하게 집어낼 수 있으니까요.
패턴을 잘 알고 있다면 가장 적합한 패턴을 찾을 수 있습니다. 만약 어떤 패턴을 써야 할지 잘 모르겠다면 문제 해결에 도움이 될만한 패턴이 있는지 훑어봐야 합니다. 이런 경우에는 패턴 카탈로그의 용도와 적용디자인의 나머지 부분에 미치는 영향이 어느 정도인지 확인해 봐야 합니다. 이 정도까지 했을 때 패턴을 써도 괜찮겠다 싶으면 그 패턴을 적용하면 됩니다.
간단한 해결책으로 문제가 해결되는데도 시스템의 어떤 부분이 변경될 거라고 예측되는 상황에는 디자인 패턴을 적용해야 합니다. 하지만 발생 가능성이 높은 실질적인 변경에 대비해서 패턴을 적용해야지, 가능성이 그리 높지 않은 가상적인 변경에 대비해서 패턴을 적용하는 일은 바람직하지 않습니다. 패턴 도입을 디자인 단계에서만 고려해야 하는 건 아닙니다. 나중에 리팩터링을 할 때도 패턴 도입을 고려할 수 있습니다.
리팩터링이란 코드를 변경해서 코드 구조를 개선하는 과정을 뜻합니다. 리팩터링의 목적은 행동 변경이 아니라 구조 개선에 있습니다. 패턴을 사용하면 구조가 더 개선될 수 있을지 검토해 볼 수 있는 아주 좋은 기회라고 할 수 있죠. 예를 들어 조건문이 아주 많은 코드가 있다면 상태 패턴의 적용도 고려해 볼만합니다. 팩토리 패턴을 써서 구상 클래스의 의존성을 말끔하게 정리할 수 있습니다.
지금 있는 디자인에서 디자인 패턴을 제거하는 일을 두려워하지 마세요.
디자인 패턴을 제거하는 일에 관해서는 거의 들어 본 적이 없죠? “어떻게 그런 짓을 할 수 있을까”라는 생각이 들수도 있습니다. 하지만 상황에 따라 그래야 할 수도 있습니다. 용기를 가지세요. 그러면 언제 패턴을 제거해야 할까요? 시스템이 점점 복잡해지면서 처음에 기대했던 유연성이 전혀 발휘되지 못한다면 패턴을 과감하게 제거해 버리는 게 낫습니다. 즉 패턴보다 간단한 해결책이 더 나을 것 같다 싶을 때 패턴을 제거하면 됩니다
디자인 패턴은 강력합니다. 그리고 온갖 방법으로 적용할 수 있습니다. 어떤 개발자든 모든식의 변화에 훌륭하게 대처할 수 있는 아름다운 아키텍처를 만들고 싶은 마음이 들것입니다. 하지만 이런 유혹을 이겨내야 합니다. 지금 당장 변화에 대처하는 디자인을 만들어야 한다면 패턴을 적용해서 그 변화에 적응해야 합니다. 하지만 꼭 필요하지 않은 데도 괜히 패턴을 추가하는 일은 피해야 합니다. 괜히 시스템만 복잡해지고, 나중에 그 패턴을 사용하지 않을 수도 있으니까요.
새로운 패턴을 만들기 전에 기존 패턴을 확실하게 파악해야 합니다. 새로워 보이는 패턴도 잘 따져 보면 기존 패턴을 변형한 것에 불과한 경우가 대부분이거든요. 패턴을 열심히 공부하다 보면 패턴을 알아보는 눈이 길러지고, 다른 패턴과 연관 짓는 능력도 발달합니다.
패턴에 관한 아이디어는 경험(접해본 문제와 사용했던 해결책)에서 나옵니다. 지금까지의 경험을 토대로 다시 한번 곰곰이 생각해보고, 반복적으로 발생하는 문제를 해결할 수 있는 새로운 디자인이 되도록 다듬어야 합니다. 완전히 새로운 패턴이라고 생각되는 것도 기존 패턴을 변형한 것에 불과할 수 있다는 사실을 기억하세요. 새로운 패턴을 발견했다고 생각했는데 적용 범위가 너무 좁아서 진짜 패턴이라고 하기 힘든 것도 많으니까요.
발견한 것을 다른 사람들이 활용할 수 없다면 새로운 패턴을 발견한 의미가 전혀 없겠죠? 새로운 패턴을 발견한 것 같다면, 다른 사람들이 직접 적용해 보고 피드백을 제공할 수 있도록 문서로 만들어 보세요. 패턴을 문서화하는 방법은 고민하지 않아도 됩니다. 이미 GoF 템플릿이 어떻게 생겼는지 알고 있잖아요. 패턴의 특성을 설명하는 방법은 이미 마련되어 있으니까, 그 문서 형식을 그대로 활용해서 발견한 패턴을 문서로 작성하기만 하면 됩니다.
패턴을 한 번에 완성하긴 힘듭니다. 새로운 패턴은 시간이 지남에 따라 점점 더 나아진다고 생각하면 됩니다. 다른 개발자들에게 본인이 발견한 패턴을 시험해 볼 기회를 제공하고, 피드백을 얻어 보세요. 그리고 패턴을 설명하는 문서에 피드백을 반영하고, 다시 검증을 받는 과정을 여러 번 반복하세요. 완벽하게 만들기는 불가능하겠지만, 계속 고치다 보면 다른 개발자들이 읽고 이해하는 데 부족함이 없는 패턴 문서를 만들 수 있습니다.
패턴이 실전 문제 해결에 3번 이상 적용되어야 패턴 자격을 얻을 수 있다는 점을 절대 잊지 마세요. 이 이유 때문에라도 다른 사람들에게 새로운 패턴을 테스트할 기회를 제공해야 합니다. 그 과정에서 점점 더 제대로 된 패턴에 가까워질 수 있습니다.
위 내용은 『헤드 퍼스트 디자인 패턴』(개정판)의 내용을 재구성하여 제작되었습니다.
현장에서 가장 많이 쓰이는 14가지 GoF 핵심 패턴에 대한 정의와 적용 방법은 책에서 더 자세히 만나보실 수 있습니다.
14가지 GoF 필살 패턴!
유지 관리가 편리한 객체지향 소프트웨어를 만드는 법
『헤드 퍼스트 디자인 패턴』한 권이면 충분합니다.
최신 콘텐츠