디자인 패턴

반복해서 나타나는 설계 문제에 대한 검증된 해결 구조와 그 이름. 복사해 쓰는 완성 코드가 아니라 객체들이 협력하는 방식을 설명하는 어휘다. 1994년 이른바 GoF(Gang of Four, 네 명의 저자)의 책 『Design Patterns: Elements of Reusable Object-Oriented Software』가 23개 패턴을 정리하며 널리 퍼졌다.

세 갈래

• 생성 패턴: 어떤 객체를 어떻게 만들지를 감춘다
• 구조 패턴: 클래스와 객체를 조합해 더 큰 구조를 만든다
• 행동 패턴: 객체 사이의 책임 분배와 대화 방식을 정리한다

패턴을 읽는 네 가지 질문

1. 어떤 변경을 쉽게 만들려는가?
2. 그 대가로 어떤 복잡성을 더하는가?
3. 패턴 없이 더 단순하게 풀 수 있는가?
4. 적용한 뒤 테스트로 지켜야 할 협력은 무엇인가?

주의

• 패턴은 목표가 아니라 수단이다. 작은 문제에 큰 패턴을 쓰면 복잡도만 늘어난다(YAGNI, 구성요소 줄이기)
• 패턴 이름을 꺼내기 전에 지금 코드의 변경 압력을 설명할 수 있어야 한다. 보통은 이름 바꾸기, 함수 추출, 조건문 정리로 충분한지 먼저 본다(리팩터링)
• 언어가 발전하면서 일부 패턴은 문법이나 표준 기능으로 대체됐다. 일급 함수가 있으면 전략 패턴·커맨드 패턴은 함수 하나로, 이터레이터는 언어의 반복 프로토콜로 충분한 경우가 많다
• Python은 덕 타이핑 덕에 구조가 느슨하고, TypeScript는 인터페이스로 협력 계약을 명시적으로 드러낸다(구조적 타이핑)

리팩터링은 지금 코드를 이런 구조로 옮겨 가는 방법이고, 패턴은 그 도착지의 이름이다. JavaScript·React 쪽 패턴은 『자바스크립트 + 리액트 디자인 패턴』, UI 구조 패턴은 MVC·MVP·MVVM에 따로 있다.

출처: Design Patterns — Refactoring.Guru