작성
·
15
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
안녕하세요. 좋은 강의 감사드립니다 !
AppConfig 클래스에서 만든 메서드를 보면
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
private MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
memberRepository의 메서드의 반환타입이 MemberRepository로 인터페이스를 반환하고 있습니다.
이때 생각해볼 수 있는 점은
MemberServiceImpl의 생성자에서 요구하는 파라미터가 인터페이스이기 때문이다라고 볼 수 있는데요,
만약 인터페이스를 반환하지 않고 구현체(MemberServiceImpl)을 반환한다면 어떤 아쉬움이 남을지 고민해보았는데 답이 나오지 않습니다 ㅠㅠ
혹시 인터페이스로 반환하게 되었을 때의 장점과 구현체를 반환하게 되었을 때의 단점을 알 수 있을까요..!?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. u_innovation님!
AppConfig 클래스에서 메서드의 반환 타입을 인터페이스로 정하는 이유에 대해 질문 주셨습니다. 이 부분은 객체지향 프로그래밍의 기본 원칙을 지키기 위한 설계적 선택입니다. 인터페이스를 반환 타입으로 사용하면 다음과 같은 장점이 있습니다:
유연성: 코드가 인터페이스에 의존하기 때문에, 구현체를 변경하더라도 AppConfig 코드에는 영향을 미치지 않습니다. 예를 들어, MemoryMemberRepository
를 JdbcMemberRepository
로 변경할 때, 인터페이스의 구현체만 바꾸면 되지, 코드를 수정하지 않아도 됩니다.
확장성: 다양한 구현체가 존재하는 경우, 인터페이스를 통해 쉽게 대체하거나 확장할 수 있습니다. 새로운 기능이 필요할 때 다른 구현체를 추가해서 사용할 수 있습니다.
테스트 용이성: 인터페이스를 통해 가짜 구현체(Mock)를 만들어서 테스트할 수 있습니다. 이는 의존성 주입(DI) 패턴과 관련이 있으며, 테스트 환경을 구성할 때 매우 유용합니다.
디커플링: 구현체에 종속되지 않으므로, 코드 간의 결합도를 낮추어 유지보수가 용이해집니다.
반면, 구현체를 직접 반환하게 되면, 위에서 언급한 유연성과 확장성, 테스트 용이성에서 오는 혜택들을 누릴 수 없습니다. 특정 구현체에 강하게 결합되기 때문에, 변경이 필요할 때마다 상당한 양의 코드를 수정해야 할 수 있습니다. 이는 유지보수 비용 증가로 이어질 수 있습니다.
이와 관련된 기존 질문들 중 유사한 주제를 다룬 내용을 공유드립니다:
이 설명을 통해 AppConfig에서 인터페이스를 반환 타입으로 사용해야 하는 이유에 대한 이해를 조금 더 깊이 하실 수 있길 바랍니다. 추가로 궁금한 점이 있으시면 언제든 질문해 주세요.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.