제 생각에는 OCP를 만족하기 위하여 if-else 나 Switch가 완전히 없어지기만 해야한다는 것은 아니라고 생각합니다.
물론 유연하게 설계되어서 그렇게 할 수 있으면 참 좋겠지만요.
- 조건문을 박는다.
- Enum으로 여러 State를 관리해서 주입받아 사용한다.
- 조건문을 통으로 Class로 추상화하여 현재 빈번하게 수정되는 현재의 소스코드 파일을 수정하는 대신 추상화된 조건문 클래스 파일 안에서 if-else를 늘려간다.
- Dictionary로 사전에 정의된 Enum이나 Class Type의 상태에 대한 동작(Action, Func, Predicate)을 item으로 계속 늘려간다.
- 동작을 외부 파일로 관리해서 파일을 읽어와서 사용하는 방식으로 한다. (최소한 리빌드는 안하도록)
- 특정 폴더 안의 모든 클래스를 읽어서 리플렉션 방식으로 처리한다.
등등 당장 머리속에 떠오르는 방식이 저정도입니다.
더 있을 거라고 생각하며, 위에 언급된 내용도 있네요.
제 생각에 가장 OCP스러운 것은 모든 상태와 동작을 class로 추상화 하는 것입니다.
if else를 늘려가는 게 아니라 class 파일이 늘어가는 것이지요.
그리고 받아 쓰는 쪽에 의존성 주입형태로 추상클래스나 인터페이스가 오는 것입니다.
하지만 if else가 코드에 있는 자체는 나쁘다고 보지 않는 편입니다.
개발자는 데드라인과 싸움하며 돈을 버는 회사원이지, 다시 없을 극한의 추상화를 꿈꾸기 보다는 비지니스 로직을 구현하는데에 시간을 부족하게 사용해서는 안된다고 생각하기 때문입니다.
그래서 데드라인까지 마감을 하고 꾸준히 리펙토링을 하려는 마인드셋 역시 테크니컬 적인 부분만큼 중요하다고 생각합니다.
결과적으로 어느 쪽을 선택할 것인지에 대한 문제라고 생각합니다.