그럼 디자인 패턴이 무엇인지에 대해 알아보자.
디자인 패턴 소개
- 인간은 패턴 인식에 최적화되어 있다.
- 프로그래밍 작업에 있어서도 귀납적으로 발견한 어떠한 패턴이 있을 것이다.
- 이렇게 소프트웨어 설계에서 흔히 겪는 문제에 대한 해결책으로 나온 것이 디자인 패턴
- 완성된 설계가 아니다.
- 특정 문제를 다양한 환경에서 해결하는 법을 설명한 가이드로 생각하자.
- GoF(Gang of Four), 1994
디자인 패턴 장단점
장점
- 이미 테스트를 마친 검증된 개발 방법을 사용해 개발 속도를 향상시킬 수 있다.
- 새 코드 작성시 곧바로 알 수 없는 문제가 있다.
- 아직 드러나지도 않았고 예측도 못한 문제들
- 증명된 패턴은 이런 문제에 대비되어 있다.
- 공통 용어 정립을 통한 개발자들 간의 빠른 의사소통을 촉진
- “XX 패턴을 사용하면 돼”로 의사소통 끝
- 단, 모두가 해당 패턴, 용어를 알고 있어야 한다.
단점
- 고치려는 대상이 잘못되었다.
- 책의 과반수는 C++ 언어의 미지원 기능에 대한 미봉책이다.
- 절반은 필요없다 라는 논문도 있었음
- 곧바로 적용할 수 없는 참고 가이드를 “패턴”이라 할 수 없다.
- 잘못 적용하는 경우가 빈번하다.
- 오히려 복잡해짐
- 비효율적인 해법이 되는 경우가 많다.
- 추상적, 범용적 => 재사용성을 고려 => 성능 저하
- 코드 중복이 많아짐
- 다른 추상화 기법과 크게 다르지 않다.
- 이미 존재하던 현상에 왜 굳이 건축 용어를 사용하는가?
디자인 패턴의 실제 목적
- 대상 독자: 이미 OO 설계를 좀 해본 프로그래머
- 새 개념이 아니라 지인끼리 공유하던 설계 방법을 정리
- OO 설계 중 발생할 수 있는 문제에 특화된 간단하고 우아한 방법
- 재활용성과 유연성을 높이기 위한 설계 방법
- 처음 읽고 이해 안되더라도 괜찮다.
- 100% 완성된 목록이 아니다.
- 현재(1994년) OO 설계에 대한 생각들을 정리한 것
- 계속 바뀔 것이라 생각한다.
94년 이후 제대로된 디자인 패턴 책이 나오지 않았다. == 해당 책에 문제가 많을 가능성이 높다.
디자인 패턴이 비판받는 실제 이유
- 커뮤니티에서 의도적으로 약을 팔았다.
- 세상이 바뀌었다.
- 자체 개발팀 증가
- 제품에 대한 인식, 비즈니스 모델 변화: 버전 별 배포, 지원 기간
- 배포 방식 변화
- Git 등의 버전 관리 시스템
- 인터넷에 더 훌륭한 해답이 많음
그러면 왜 배우나
- 그래도 여전히 언급되기 때문에, 알아두기는 하려고.
- 그나마 몇 개 많이 쓰이는 패턴이 있다.
- 하지만 대부분은 다형성에 기반한 추상화에 기초한다.
디자인 패턴 공부법
- 디자인 패턴 배웠다고 쓸생각하지 말 것.
- 내 코드가 정확히 어떻게 도는지 이해되기 전까진 X
- 스택 오버플로우에서 해법을 먼저 찾을 것
- 남의 코드를 보고 추상적으로 이해가 되는 수준까지 기다려라.
- 모자란 실력을 숨기지 마라.
여기서 배울 패턴들
- 20. Factory Method
- 21. Builder
- 08. Singleton
- 22. Wrapper(Adapter)
- 23. Proxy
- 24. Chain of Responsibility
- 25. Observer