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

강민주님의 프로필 이미지
강민주

작성한 질문수

스프링 핵심 원리 - 기본편

관심사의 분리

AppConfig의 역할이 Service의 구현 객체가 아닌 Repository 구현 객체를 리턴하도록 구현하면 안되나요?

작성

·

237

0


[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예

[질문 내용]

강의에선 AppConfig의 역할이 Service에 적절한 Repository 구현체를 주입해 Service 구현 객체를 리턴하는 것이라고 이해했습니다.
그러나, 아래와 같이 AppConfig와 MemberServiceImpl을 구현하지 않는 이유는 무엇인가요?
 
또한, 아래의 코드에서도 MemberServiceImpl은 외부 객체를 통해 객체의 생성과 선택을 위임한다는 점에서 여전히 의존관계를 주입받고 있다고 생각하는데, 제가 이해한 바가 맞나요?
 
public class AppConfig {

  public static memberRepository() {
    return new MemoryMemberRepository();
  }
  
  public MemberService memberService() {
    return new MemberServiceImpl();
  }
}


public class MemberServiceImpl implements MemberService {

  private final MemberRepository memberRepository = AppConfig.memberRepository();

  @Override
  public void register(Member member) {
    memberRepository.save(member);
  }

  @Override
  public Member findMemberBy(Long memberId) {
    return memberRepository.findById(memberId);
  }
}

답변 1

4

안녕하세요. 강민주님, 공식 서포터즈 David입니다.

작성하신 것은 다른 객체를 통해 의존관계인 객체를 생성하는 관점에는 괜찮지만 MemberServiceImpl이 AppConfig에 의존하게 됩니다. 

생성자 주입을 이용하면 MemberServiceImpl이 AppConfig에 의존하지 않고 MemberRepository를 주입받을 수 있습니다. 즉, 불필요한 의존관계를 가질 필요가 없다는 말입니다. 굳이 예를 들어 보자면 AppConfig가 아닌 다른 설정 클래스(AppConfig2)로부터 MemberRepository를 주입 받아야 하는 상황이 있다면 AppConfig에 의존하고 있는 MemberServiceImpl은 수정대상이 됩니다.

감사합니다.

저도 이 생각을 했었는데 David님이 주신 답변으로 의문점이 해결되었습니다.

코드를 작성하면서 느끼는거지만 인터페이스가 내부적으로 동작에 필요한 역활을 주고 역활을 수행할 객체는 어플리케이션에서 실행시킬때 주입시켜 동작하는 형태을 하는것 같아요

그렇게 될려면 클라이언트 코드에는 구현 아닌 인터페이스에 의존하는 코드가 나와야하고 저 코드에서 의존 관계를 해결하기위해서는 생성자 주입 통해서 해결이 가능해보여요

 

강민주님의 프로필 이미지
강민주

작성한 질문수

질문하기