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

모모토님의 프로필 이미지
모모토

작성한 질문수

스프링 핵심 원리 - 기본편

AppConfig 리팩터링

AppConfig에서 중복이라는 개념이 궁금한데요

작성

·

276

0

AppConfig가 DIP와 OCP를 해결하기 위하여

MemberServiceImpl 과 OrderServiceImpl에 'new MemoryMemberRepository' 를 주입하는 역할을 하잖아요?

근데 리팩토링 하기전에는 orderService() 와 memberService() 에서 'new MemoryMemberRepository' 를 각각 따로 생성하는걸 중복이라고 보고

이를 해결하기 위해서 리팩토링하여 memberRpository() 를 만들어 한번만 생성하도록 하여 중복을 막으신거라고 이해해도 괜찮은가요??

답변 1

8

안녕하세요?

같은 코드의 반복을 한곳에 정리한다는 면에서 중복을 막는 리팩터링이라고 표현해도 맞습니다.

더 중요한 의미는 어떤 객체 안에서 new 키워드를 사용해서 특정 객체를 직접 생성하지 않는 것입니다.

.

만약 객체 안에서 new 키워드를 사용할 경우 코드는 아래와 같아집니다.

// 메모리로 구현한 멤버리포지터리를 사용할 때
MemberRepository memberRepository = new MemoryMemberRepository();

// 개발이 끝나고 이제 메모리대신 마리아DB를 이용하는 리포지터리로 바꿔야지!
MemberRepository memberRepository = new MariaMemberRepository();

// 사장님이 데이터베이스를 오라클로 바꾸자고 하심.... ㅠㅠ
MemberRepository memberRepository = new OracleMemberRepository();

.

MemberRepository라는 동일한 객체를 사용하고 있는데

구현체가 바뀔때마다 코드를 수정해야 하는 번거로움이 있습니다.

(MemoryMemberRepository 클래스가 오라클을 이용하게 바꾸면 나머지 코드는 안바꿔도 되는데? 라고 생각하신다면 당신은 편법의 천재..?)

직접 생성하지 말고 외부에서 주입을 받으면 어떨까요?

class MemberSerivce {

    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

.

위와같이 이제 구현체가 어떤것이되었든 서비스 클래스를 수정할 필요 없습니다. 리포지터리의 사용법이 바뀌지 않는한 서비스는 제대로 동작한다고 신뢰할 수 있습니다.

.

구현체로부터 자유로워 졌으니 '확장에는 열려있고' 서비스 코드를 수정할 필요가 없으니 '수정에는 닫혀있다'  OCP 를 만족한다고 할 수 있습니다.

모모토님의 프로필 이미지
모모토
질문자

정성스러운 답변 늦게봐서 죄송합니다 그리고 감사합니다! 참고해서 더 열심히 공부할께요!

모모토님의 프로필 이미지
모모토

작성한 질문수

질문하기