1. 디자인 패턴이란?

• 정의:

  • 반복 출현하는 설계 문제를 문제-맥락-해법 템플릿으로 정리한 이름 있는 해결책

  Someone has already solved your problems.

• 패턴 ≠ 코드 스니펫

  → 설계 수준의 역할·책임·협력에 대한 약속(의도·트레이드오프 포함)

• 효과

  • 팀의 공유 언어
    • e.g.) “여긴 Strategy” 한마디로 의도/구조가 전달
  • 재사용 가능한 구조 습득, 설계 품질(확장성/유지보수성/가독성) 상승
  • 리뷰·온보딩 속도 ↑, 설계 토론 비용 ↓

• 경험

  • 코드가 아니라 설계 지침
  • 발명된 게 아니라 발견된 것 (여러 개발자가 쌓아온 경험)
  • 변화에 대응하는 방법

2. 왜 필요한가?

The one constant in soft ware development is CHANGE.

• 좋은 OOP 설계 = 재사용성 + 확장성 + 유지보수성.
• 문제 상황:
  • 요구사항이 바뀜 → 모든 코드가 바뀜 → 테스트/확장 비용, 시간 증가
  • 상속으로 공통화 → 예외가 생기는 순간 빈 오버라이드/플래그 분기/중복 확산
  • 결과: if-else/switch 지옥, 테스트 어려움, 결합도↑, 버그율↑
  • ⇒ 변하는 것을 식별해 고정된 것과 구조적으로 분리
• OOP 개념을 잘 안다고 해도, 유연하게 만들수 있어야 한다.
• 결국 변하는 것과 변하지 않는 것을 분리하는 게 관건
• 즉, “디자인 패턴”은 사실 원칙을 잘 활용한 결과물이다.

3. Strategy Pattern!

1) 문제 상황

• 객체의 동작(알고리즘) 이 자주 바뀐다.
• 상속으로 해결하려다 보면 하위클래스 폭발, 중복/불일치 발생, 공통 변경이 어렵다.