다섯 원칙의 약자를 외워 왔는지, 아니면 각 원칙을 자기 경험·도메인 사례로 풀고 과적용의 부작용까지 말할 수 있는지를 가른다.
SOLID는 객체지향 설계에서 변경 비용을 낮추기 위한 다섯 원칙이다 — SRP(단일 책임), OCP(개방-폐쇄), LSP(리스코프 치환), ISP(인터페이스 분리), DIP(의존 역전). 핵심은 "무엇이 같이 바뀌어야 하는지"를 한 군데로 모으고(SRP), 새로운 요구가 들어와도 기존 코드를 뜯어고치지 않고 확장으로 흡수하며(OCP), 구체 클래스에 직접 매달리지 않고 추상에 의존하도록(DIP) 흐름을 정리하는 것이다. 다섯 원칙은 따로 외워도 의미가 약하다 — "변경 축을 어디에 두는가"라는 한 가지 질문의 다섯 가지 답이다.
기능 한두 개 추가할 때마다 if 분기가 늘던 코드를 전략 패턴·인터페이스 분리로 정리한 경험이 있다면 OCP의 실제 효과로 풀어낼 수 있다
외부 API 클라이언트를 인터페이스로 빼서 단위 테스트가 쉬워진 경험이 있다면 DIP·테스트 용이성 이야기로 이어갈 수 있다
SRP 명목으로 너무 잘게 쪼갠 클래스 때문에 오히려 흐름 추적이 어려워진 경험이 있다면 "과적용의 비용" 사례로 균형 있게 보여 줄 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.