08) 의존성 관리하기

1. 의존성

어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다고 말한다. 의존성은 변경에 의한 영향의 전파 가능성을 암시한다.

 

협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다. 객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는데 있다.

 

1.1 의존성 전이

영화예매에서의 코드를 떠올려보자. 만약 할인조건이 예매에 의존할경우 할인조건은 예매가 의존하는 대상에 대해서도 자동적으로 의존하게 된다. 다시 말해 예매에 영화정보, 날짜, 고객수가 의존할 경우 할인조건 역시 간접적으로 영화정보, 날짜, 고객수에 의존하게 된다.

할인조건 ---> 예매 ----> 영화정보, 날짜 ...

의존성은 함께 변경될 수 있는 가능성을 의미하기 때문에 모든 경우에 의존성이 전이되는 것은 아니다. 의존성 전이는 변경에 의해 영향이 널리 전파될 수도 있다는 경고일 뿐이다. 의존성의 종류로 직접 의존성과 간접 의존성이 있다.

• 직접 의존성 : 한 요소가 다른 요소에 직접 의존하는 경우
  • 할인조건이 예매에 의존하는 경우
• 간접 의존성 : 직접적인 관계는 존재하지 않지만 의존성 전이에 의해 영향이 전파되는 경우

 

1.2 런타임 의존성, 컴파일타임 의존성

• 런타임 : 애플리케이션이 실행되는 시점
• 컴파일타임 : 작성된 코드를 컴파일하는 시점, 코드 그 자체

 

객체지향 애플리케이션에서 런타임의 주인공은 객체다. 따라서 런타임 의존성이 다루는 주제는 객체 사이의 의존성이다. 반면 코드 관점에서 주인공은 클래스다. 따라서 컴파일타임 의존성이 다루는 주제는 클래스 사이의 의존성이다.

코드 작성 시점의 영화와 할인 정책 사이의 의존성

영화의 인스턴스가 가지는 런타임 의존성

 

코드 작성 시점의 영화 클래스는 할인 정책을 구현한 두 클래스의 존재를 모르지만 실행 시점의 영화 객체는 두 클래스의 인스턴스와 협력할 수 있게 된다. 어떤 클래스의 인스턴스가 협력하기 위해서는 협력할 인스턴스의 구체적인 클래스를 알아서는 안된다. 협력할 객체가 어떤 것인지는 런타임에 해결해야 한다. 따라서 컴파일타임 구조와 런타임 구조 사이의 거리가 멀수록 설계가 유연해지고 재사용 가능해진다.

 

 

2. 유연한 설계

2.1 의존성과 결합도

의존성은 객체들의 협력을 가능하게 만드는 매개체라는 관점에서는 바람직한 것이다. 하지만 의존성이 과하면 문제가 될 수 있다. 그렇다면 바람직한 의존성이란 뭘까? 이에 답은 재사용성과 관련이 있다. 어떤 의존성이 다양한 환경에서 클래스를 재사용할 수 없도록 제한한다면 그 의존성은 바람직하지 못한 것이다. 반대로 재사용할 수 있다면 그 의존성은 바람직한 것이다. 즉 바람직한 의존성이란 컨텍스트에 독립적인 의존성을 의미하며 다양한 환경에서 재사용될 수 있는 가능성을 열어놓는 의존성을 의미한다.

 

결합도의 정도는 한 요소가 자신이 의존하고 있는 다른 요소에 대해 알고 있는 정보의 양으로 결정된다. 더 많이 알수록 더 많이 결합된다. 이에 대한 정답은 추상화에 있다. 의존하는 대상이 더 추상적일수록 결합도는 더 낮아진다.

 

의존성은 명시적으로 표현돼야 한다. 유연하고 재사용 가능한 설계란 퍼블릭 인터페이스를 통해 의존성이 명시적으로 드러나는 설계다.