디자인 패턴은 실제로 가지고 있는 진짜 문제를 해결할 때 가치가 있습니다 — 하지만 맞지 않는 곳에 강제하면 과도한 엔지니어링을 유발합니다. 언제 패턴을 사용할지(그리고 언제 사용하지 않을지)에 대한 좋은 판단은 패턴을 아는 것만큼 중요합니다.
실제 문제에 맞을 때 패턴을 사용하라
✓ 패턴이 해결하도록 설계된 문제가 있을 때 (상황을 인식)
✓ 패턴이 진정으로 코드를 더 낫게 만들 때 (더 유연, 유지보수 가능, 명확)
✓ 추가된 구조가 실제 필요(실제로 사용할 유연성)로 정당화될 때
✓ 커뮤니케이션을 개선할 때 (다른 사람이 인식할 잘 알려진 패턴)
→ 패턴은 특정 문제를 위한 도구 → 알맞은 문제에 적용하라
패턴을 강제하지 마라 (과도한 엔지니어링을 피하라)
✗ 단지 쓰기 위해 패턴을 추가하지 마라 ("패턴을 위한 패턴") → 불필요한 복잡성을 더함
✗ 과도하게 엔지니어링하지 마라 → 패턴은 추상화/간접성을 더함; 필요 없다면
그것은 아무 이유 없는 복잡성
✗ 이른 추상화를 피하라 → (아직) 필요 없는 유연성을 만들지 마라 (YAGNI)
✗ 단순하고 직접적인 해결책이 패턴 중심 해결책보다 종종 더 나음
→ 패턴을 남용하면 코드가 더 복잡하고 이해하기 어려워짐 (목표와 반대)
