무조건 인터페이스-구현체 를 나누는게 좋은 건 아니겠죠 ???

Question

모든 상황에서 인터페이스(DiscountPolicy)-구현체(FixDiscountPolicy) 처럼 나누는게 좋은 건 아니겠죠 ??

지금 상황처럼 정책이 바뀔 경우가 없다면 그냥 바로 구현체를 만드는 게 더 효율적인 것 같은데, 설계상 정책이 안바뀐다 하더라도 만약의 상황을 대비해 인터페이스를 만들어두는편인가요 ??

Answer

안녕하세요. 팡휘님, 공식 서포터즈 OMG입니다.인터페이스를 가져가는 개발 구조에서의 추상화라는 비용이 발생하는 것을 잘 캐치하신 것 같습니다.다음 링크의 영한님 답변을 참고해주세요 😀https://www.inflearn.com/questions/69278/service%EB%A0%88%EC%9D%B4%EC%96%B4%EB%A5%BC-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4%EB%A1%9C-%EC%B6%94%EC%83%81%ED%99%94-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94감사합니다.

팡휘

무조건 인터페이스-구현체 를 나누는게 좋은 건 아니겠죠 ???

이 글과 비슷한 Q&A

강의 스트리밍 에러

실무에서 spring boot 2.6.x 버전을 사용 하고 있는데요.

테스트 실패: Unsatisfied dependency expressed through field 'prototypeBeanProvider'

컨트롤러 메서드명을 명사로 지어도 되나요?