코드를 작성하다보면 으레 고민해야 하는 문제들이 있다. 객체를 어떻게 어디에서 생성할지, 객체 간 소통을 어떻게 하도록 설계해야 할지, 반복되는 코드들을 어디에서 관리할지 등... 개발을 공부하고 나서 초반에는 그냥 되는대로 작성했었다. 그렇다보니 즉흥적이고 규칙없이 직관성없는 스파게티 코드가 되기 일쑤였다.
디자인패턴은 이러한 문제들에 대해 검증된 해결책을 정리해놓은 설계 템플릿이라고 할 수 있다. 1994년 GoF(Gang of Four)라고 불리는 네명의 개발자가(그래서 four구나..) 디자인 패턴 23개를 정리하면서 알려지게 되었다고 한다.
디자인패턴, 왜 사용해야 할까?
- 커뮤니케이션이 수월해진다.
- 검증된 구조를 재사용할 수 있다.
- 유지보수하기 좋다.
디자인 패턴을 3가지로 분류하면
1. 생성 패턴
말 그대로 객체를 어떻게 만들것인가에 관한 패턴이다. 객체 생성 방식을 유연하게 만들어준다.
| 패턴 | 내용 |
| Singleton | 인스턴스를 딱 하나만 생성 |
| Factory Method | 객체 생성을 서브클래스에 위임 |
| Abstract Factory | 관련 객체들을 묶어서 생성 |
| Builder | 복잡한 객체를 단계적으로 생성 |
| Prototype | 기존 객체를 복사해서 생성 |
2. 구조 패턴
클래스나 객체를 어떻게 조합할 것인가에 대한 패턴이다. 유연하고 재사용가능한 코드를 짜기 위해 알아두면 좋은 패턴이다.
| 패턴 | 내용 |
| Adapter | 호환되지 않는 인터페이스를 연결 |
| Decorator | 기능을 동적으로 추가 |
| Composite | 트리 구조로 객체 구성 |
| Facade | 복잡한 서브시스템을 단순한 인터페이스로 |
| Bridge | 구현과 추상화를 분리 |
| Flyweight | 공유로 메모리 절약 |
| Proxy | 대리 객체로 접근 제어 |
3. 행위 패턴
객체 간 어떻게 소통하고 책임을 가져갈 것인가에 대한 패턴이다. 간단하게 역할 분담에 대한 패턴이라고 할 수 있다.
| 패턴 | 내용 |
| Observer | 상태 변화를 구독자에게 알림 |
| Strategy | 알고리즘을 캡슐화해서 교체 가능하게 |
| Template Method | 알고리즘 골격을 정의하고 세부는 서브클래스에 |
| Command | 요청을 객체로 캡슐화 |
| Iterator | 컬렉션 순회 방법을 표준화 |
| Chain of Responsibility | 요청을 체인으로 전달 |
| State | 상태에 따라 행동 변경 |
| Mediator | 객체 간 통신을 중재자가 담당 |
| Memento | 상태를 저장하고 복원 |
| Visitor | 구조와 동작을 분리 |
| Interpreter | 언어의 문법을 정의 |
디자인 패턴은 뭐 CS 지식처럼 무조건 외워야 하는 공식은 아니라고 생각한다. 단지 상황에 맞게 꺼내서 쓰는 도구이고, 도구는 많을수록 좋은 법이니까 기억해뒀다가 써먹으면 좋다! 실제로 나도 멘토에게 코드 리뷰를 받으면서 디자인패턴을 패턴을 적용해 보면 어떻겠냐는 피드백을 받아서 알게 된 부분이기도 하다.