역할과 구현 분리 이유

역할과 구현을 분리하는 이유가 궁금한데요. 어떤 역할(ex. 회원 데이터 저장하기)에 대한 구현 방법이 여러가지이기 때문인가요? (구현 방법이 여러가지라면 구현법을 변경할 가능성이 있기에) 이게 역할과 구현을 분리하는 이유인가요?

그렇다면 어떤 역할에 대한 구현 방법이 단 1가지라면 역할과 구현을 분리하지 않아도 되는 것인가요? 만약 그렇다면 '구현체가 1개인 경우에는 인터페이스명 + Impl을 클래스명으로 하는 것이 관례'라는 관례가 존재하는 이유가 무엇인가요? 구현체가 단 1개라면 인터페이스-클래스가 아닌 클래스만 존재하면 되는거 아닌가요...?

안녕하세요. 도토리님, 공식 서포터즈 y2gcoder입니다.

먼저 역할과 구현을 분리하는 이유에 대해서는 본 강의의 섹션 1. 객체 지향 설계와 스프링 > 좋은 객체 지향 프로그래밍이란? 이상으로 설명할 자신이 없기 때문에 해당 강의를 다시 한 번 봐주시면 감사하겠습니다!

그리고 역할과 구현을 나누는 추상화에도 비용이 존재합니다. 이 부분에 대해서는 다음 링크(클릭)을 참고해주십쇼! 실무에서는 구현체를 교체할 가능성이 없는 경우는 말씀하신 것처럼 실용적으로 클래스만 만드는 경우가 많습니다! 예를 들어 Controller 클래스는 보통 인터페이스 없이 구현체만 만들고 있습니다!

마지막으로 인터페이스에 유일한 구현체의 관례가 "인터페이스명+Impl"인 이유에 대해서는 정확하게는 모르겠습니다. 다만 추후 변경을 대비해서든지 회사 컨벤션이든지 등의 이유로 인터페이스-구현체 로 나눴을 때 해당 인터페이스명과 구분하면서 해당 인터페이스의 구현체임(Implement 를 줄여 Impl로)을 표현해주기 위해 이러한 관례가 생겼을 것이라 조심스럽게 추측합니다!

감사합니다.

인프런 커뮤니티 질문&답변