작성
·
167
0
금융업 it업계에 종사하는 개발자입니다.
isp에 대해 어렴풋이 알고 있다가 강사님의 강의를 보면서
지난 리팩토링 과정에서 제가 겪었던 문제에 답이 될 수 있을 것
같아서 질문드립니다.
인증서라고 하는 비즈니스가 하나의 소스 코드에 if else로 분기처리되어있는 것을 각 인증서라는 인터페이스를 두고, 요청으로 온 구분코드에 따라 서로 다른 구현체를 생성하도록 했습니다.
이때 한가지 문제가 인증서 별로 기능이 상이하다는 것이었는데요. 발급, 폐기, 환불 등의 기본적인 기능들은 모두 제공하지만 갱신, 강제폐기/환불 등 특정 인증서에서만 구현되는 기능들이 있을 때 강의에서 말씀하신 isp를 위반하는 상황이 발생할 거라고 생각했습니다. 그렇다면 공통기능에 대한 인터페이스, 특정기능에 대한 인터페이스를 분리하자라는 생각까지 해보았는데,, 이렇게 됐을 때 공통기능을 구현하지않는 또 다른 인증서 상품이 신규 됐을 때 문제가 될거라는 생각이 들었습니다. 다른 방식으로 발급, 폐기, 환불 등 각각의 기능들을 인터페이스화 하자면 각 구현체별로 구현하는 인터페이스가 너무 많아지는게 아닐까 하는 생각도 들었습니다.
이럴 경우에는 어떻게 설계에 접근해야할지 고견을 여쭙니다. 혹 이럴 때 용이한 디자인패턴 같은게 있는지요.
긴 글 읽어주셔서 감사합니다.
답변 2
0
안녕하세요, 인생은회전목마 님!
말씀주신 상황을 보았을 때, 저였어도 같은 고민을 했을 것 같은데요. 아무래도 특별한 방법이 더 있다기 보다는, 이미 알고계신대로 인터페이스를 잘게 쪼개어 적용하는 방법이 제일 나아보입니다.
다만 인터페이스가 너무 많아지는 것을 고려하신다면, 각 기능 단위로 인터페이스를 모두 쪼개는 대신, 공통 기능 N개를 정의한 인터페이스 하나와 특수한 기능 하나를 정의한 인터페이스 M개를 두고 조합하여 사용해볼 수 있을 것 같아요.
만약 전에 없던 새로운 인증서가 추가된다면, 그건 또 그때의 상황에 맞게 인터페이스를 더 쪼개는 등 다시 리팩토링하겠다는 방향으로 접근해보면 좋을 것 같습니다. 현재까지 드러나 있는 도메인 지식을 기반으로, 최선을 고려하여 구조를 잡으면 될 것 같아요.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
인생은회전목마님께서 인터페이스 분리 원칙(ISP)에 대해 질문해 주셨네요. 인터페이스 설계는 소프트웨어 설계에서 매우 중요한 주제입니다. 특히, 다양한 요구사항이 존재하는 시스템에서는 더욱 그렇습니다.
여러 개의 인터페이스로 분리:
장점과 단점 고려:
자주 사용되는 전략 패턴:
이와 관련하여 유사한 고민을 다룬 게시물을 추천드립니다. 이 글들이 도움이 되길 바랍니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.