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

강의를 수강하지 않았지만 질문 주신 내용을 토대로 답변 남겨봅니다.

의존성 주입(DI)이 OCP와 DIP를 지원하는 기술이지만, DI를 사용한다고 해서 원칙들이 지켜지는 것은 아닙니다. OCP와 DIP 원칙을 제대로 적용하기 위해서는 설계에 대한 고민이 필요합니다.

MemberRepository를 구체 클래스로 직접 의존할 경우, MemberService는 MemberRepository의 변화에 직접적인 영향을 받게 됩니다. 예를 들어, MemberRepository를 NewMemberRepository로 변경해야 할 때 MemberService의 코드도 함께 수정해야 하는 상황이 발생합니다. 이는 OCP와 DIP 원칙을 위반하게 됩니다.

이 문제를 해결하기 위해서는 MemberRepository의 인터페이스(추상화)를 정의하고, MemberService가 이 인터페이스에 의존하도록 설계해야 합니다. 이렇게 하면 MemberService는 MemberRepository의 구체적인 구현에 독립적이 되어, 구현체가 변경되어도 MemberService의 코드를 수정할 필요가 없어집니다.

이해를 위해 아래에 구체 클래스 의존과 인터페이스 의존의 예시 코드 남겨봅니다. DIP와 OCP 원칙에 대해 학습해보시고 직접 코드를 작성해보시면 금방 이해하실 수 있을거라고 생각합니다.

구현체 의존 예시 (DIP, OCP 원칙 위반)

// OriginMemberRepository 사용
@Service
public class MemberService {
    private OriginMemberRepository memberRepository; // DIP 위반

    public void setMemberRepository(OriginMemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

@Repository
public class OriginMemberRepository {
    public void save(String member) {
        System.out.println("원래 구현체");
    }
}

// OriginMemberRepository -> NewMemberRepository 변경
@Service
public class MemberService {
    private NewMemberRepository memberRepository; // 코드 변경(OCP 위반)

    public void setMemberRepository(NewMemberRepository memberRepository) { // 코드 변경(OCP 위반)
        this.memberRepository = memberRepository;
    }
}

@Repository
public class OriginMemberRepository {
    public void save(String member) {
        System.out.println("원래 구현체");
    }
}

@Repository
public class NewMemberRepository {
    public void save(String member) {
        System.out.println("새로운 구현체");
    }
}

인터페이스 의존 (DIP, OCP 원칙 준수)

// OriginMemberRepository 사용
@Service
public class MemberService {
    private MemberRepository memberRepository;

    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

public interface MemberRepository {
    void save(String member);
}

@Repository
public class OriginalMemberRepository implements MemberRepository {
    @Override
    public void save(String member) {
        System.out.println("원래 구현체");
    }
}

// OriginMemberRepository -> NewMemberRepository 변경
@Service
public class MemberService {
    private MemberRepository memberRepository; // 코드 변경 없음

    public void setMemberRepository(MemberRepository memberRepository) { // 코드 변경 없음
        this.memberRepository = memberRepository;
    }
}

public interface MemberRepository {
    void save(String member);
}

@Repository
public class OriginalMemberRepository implements MemberRepository {
    @Override
    public void save(String member) {
        System.out.println("원래 구현체");
    }
}

@Repository
@Primary
public class NewMemberRepository implements MemberRepository {
    @Override
    public void save(String member) {
        System.out.println("새로운 구현체");
    }
}

OCP가 지켜지는것 처럼 보이지만 클라이언트가 결국 setMemberRepository함수를 직접 호출해야하는 책임이 있구요.MemberRepository의 새로운 구현체를 추가할 때마다 setMemberRepository()를 호출하는 코드도 변경될 가능성이 있습니다.OCP는 기존 코드를 수정하지 않고도 확장할 수 있어야 한다는 원칙을 의미하므로, 이 경우 완벽히 OCP를 준수했다고 보기 어렵습니다.

그리고 OCP는 생성자 주입 방식을 선호합니다.(이건 인강에서 따로 공부해보십쇼)

안녕하세요, 인프런 AI 인턴입니다. 박도현님.

OCP(Open-Closed Principle) 원칙은 “확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다”는 의미로, 코드의 확장 가능성을 열어두면서 기존 코드를 변경하지 않는 방법을 강조합니다.

질문하신 내용은 의존성을 주입(DI, Dependency Injection)하여 클라이언트 코드에서 직접 구현 클래스를 할당하지 않도록 변경하는 방식입니다. setMemberRepository(m)처럼 외부에서 의존성을 주입하여 Client Code(예: MemberService) 내부를 변경하지 않고도 MemberRepository의 구현체를 바꿀 수 있게 됩니다. 이 과정에서 MemberService의 의존성을 외부로 넘기면서, 클라이언트 코드가 직접적으로 의존하는 것을 줄이게 됩니다.

즉, 문의해주신 방식으로 외부에서 구현 클래스를 주입할 경우, 구현 클래스를 변경하기 위해 클라이언트의 내부 코드를 수정할 필요가 없어지는 이점이 있습니다. 이로 인해, 이 방식은 OCP를 지키는 것에 적합하다고 할 수 있습니다.
이를 통해 구현체의 변경이나 추가가 필요한 경우에도 기존 클라이언트 코드는 변경되지 않기 때문입니다. 이는 코드의 유연성과 확장성을 보장하는 방법 중 하나입니다.

다음 링크는 유사한 주제를 다룬 질문입니다. 도움이 되실 수 있도록 참조해 보세요:
- 의존관계, 레퍼런스, DIP

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.