패턴 정의를 외웠는지가 아니라, 언제 조건문 대신 전략 분리를 고를지에 대한 자기 기준이 있는지 본다. "if문이 길어지면 전략 패턴" 수준에서 그치는지, 변화 축·책임 경계 같은 기준어를 들고 오는지가 가장 큰 갈림길이다.
전략 패턴은 같은 목적을 가진 알고리즘·정책을 공통 인터페이스로 묶고, 런타임에 어느 구체 전략을 쓸지 갈아끼우는 패턴이다. 핵심은 "if-else로 정책을 계속 덧붙이는 코드"를 "변화 축마다 객체로 떼어내는 구조"로 바꾸는 데 있다. 컨텍스트는 전략 인터페이스에만 기대므로 새 정책을 더할 때 기존 분기 코드를 다시 깨우지 않아도 된다. 단, 전략이 두세 개뿐이거나 변화 가능성이 낮은 영역에 도입하면 추상화 비용이 도메인 이득을 못 따라잡으니, 변화 빈도와 책임 경계를 기준으로 들이느냐 마느냐를 갈라야 한다.
if-else가 길어진 코드를 전략으로 떼어낸 경험이 있다면, 그때 무엇을 "변하는 축"으로 봤는지를 답변의 결정 기준으로 가져올 수 있다
전략을 인터페이스 단위로 테스트하면서 변경 안정성이 올라간 경험이 있다면 테스트 관점의 이득을 본인 사례로 풀 수 있다
오히려 과도한 추상화로 추적이 어려워진 경험이 있다면 "전략 패턴을 안 들이는 기준"을 본인 사례로 말할 수 있다
DI 컨테이너에서 전략 빈을 등록·선택하며 설정과 책임 경계를 정리한 경험이 있다면 컨텍스트·전략의 결합도 이야기로 자연스럽게 이어진다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.