(Java) 패키지 양방향 의존 문제점과 해결 방안

목차

---

1. 패키지 양방향 의존성 문제점

2. 해결 방안

---

1. 패키지 양방향 의존성 문제점

우리는 팀 단위로 프로젝트 진행할 때 보통 메뉴 or 도메인 단위로 패키지를 구성한 뒤 담당자가 배정된다. (모놀리식 프로젝트인 경우)

그때 작업자들은 필연적으로 다른 개발자가 개발 중인 패키지의 서비스 등을 사용할 경우가 생긴다.

그러면 해당 개발자는 일단 해당 서비스를 의존 주입 받아서 바로 사용하고 싶은 욕구가 생길 텐데 이때 아래와 같은 문제가 생길 수 있다.

 

현재 주문 패키지와 결제 패키지가 있고 각기 다른 개발자가 담당하여 개발중이라고 해보자.

 

주문 서비스

package com.example.ordersystem;

public class OrderService {
    private PaymentService paymentService = new PaymentService();

    public void placeOrder(OrderDetails orderDetails) {
        paymentService.processPayment(orderDetails);
    }
}

 

결제 서비스

package com.example.paymentsystem;

public class PaymentService {
    public void processPayment(OrderDetails orderDetails) {
        // 결제 처리 로직
    }
}

 

현재 주문 서비스 로직 완료 후 결제 패키지의 결제 서비스를 사용해야 하여 위 처럼 코드를 작성했다.

그리고 해당 코드는 아래와 같은 문제점이 있다.

• 결제 서비스의 processPayment 메서드명이나 매개 변수가 바뀌면 주문 서비스도 변경해야 한다.
• 주문 서비스의 OrderDetails 객체의 변경이 결제 서비스의 processPayment 메서드도 영향을 받는다.

diagram으로 표현하면 아래와 같다. (빨간 박스는 패키지를 의미)

* 참고로 A -> B 표현은 B의 변경이 A에 영향을 끼친다는 의미이다.다른 말로 A는 B에 의존한다고 함.

패키지 간 양방향 의존

2. 해결 방안

 

위의 상황에서 문제점에 대해 파악을 했으니 해결 방안을 알아보자.

현재 문제점은 패키지 단위로 작업을 맡은 개발자 두 명이 각각의 코드를 수정하면 서로 영향을 끼치는 것이다.

 

유일한 해결 방안은 아니지만 가장 간단한 방법 중 하나는 DIP를 사용하여 의존성의 방향을 바꾸어
한쪽으로 통일 시키는 방법이다. diagram을 통해 표현하면 이렇다. (빨간 박스는 패키지를 의미)

한쪽으로 흐르는 패키지 의존성

이제 어떤 부분이 개선 되었는지 한 번에 보일 것이다.

기존 OrderService -> PaymentServiceImpl 의존 관계를 없애고 같은 패키지인 PaymentService로 변경되었다

 

그러면 더 이상 주문 패키지는 결제 패키지 변경에 아무런 영향을 받지 않게 된다.

결론적으로 사이드 이펙트가 훨씬 줄어 좀 더 안정적인 코드가 되었다.