OOAD - 데이터 주도 설계의 문제점(결합도와 응집도)

이번 포스팅에서는 지난 포스팅에서 다루었던 책임주도 설계와 대비하여 소개되는 데이터 주도 설계 방식을 알아보고  결합도와 응집도에 대해 알아보도록 하겠습니다. 이 포스팅은 OBJECTS(코드로 이해하는 객체지향 설계)라는 책을 토대로 작성되었습니다.

 

 

지난 포스팅 ( https://galid1.tistory.com/681 )과 이어 보시는것이 도움이 더 많이 될것입니다.

 

 

 

데이터 주도 설계

데이터 주도설계란 간단히 말씀드려 객체가 가져야할 데이터에 초점을 두고 설계를 하게되는 방식을 일컫습니다. 데이터 주도 설계에서는 객체 자신이 포함하고 있는 데이터를 조작하는 데 필요한 행동을 정의하게 됩니다. 반면 책임주도 설계에서는 다른 객체로부터 자신에게 요청할 수 있는 요청을 수행하기 위해 필요한 상태를 보관하게 됩니다.

 

앞으로 제가 하게 될말의 결론을 말씀드리자면, 데이터 주도 설계보다는 책임 주도 설계방식에 초점을 맞추어야 올바른 설계가 될 수 있습니다. 왜냐하면 데이터(상태)의 경우 구현에 속하는데 구현은 항상 불안정하고 변화할 수 있기 때문입니다. 반면 책임(행동)의 경우 인터페이스에 속하며 상대적으로 안정적인 편에 속하게 됩니다.

 

 

예를 들며 설명드리도록 하겠습니다. *이전 포스팅을 보고 오셔야 내용이 이어집니다.

 

1. 데이터 주도설계를 이용한 영화예매 시스템 설계

데이터 중심의 설계에서는 먼저 객체가 내부에 저장해야할 데이터가 무엇일까? 라는 질문으로부터 시작됩니다.

 

xxxxxxxxxx
public class Movie {
    private String title;
    private Duration runningTime;
    private Money fee;
    private List<DiscountCondition> discountConditions;
    
    private MovieType movieType;
    private Money discountAmount;
    private double discountPercent;
    
    public String getTitle() {
        return this.title;
    }
    
    public void setTitle(String newTitle) {
        this.title = newTitle;
    }
    
    ...
}

Movie에서 예매금액을 계산하기 위해서는 어떤 데이터가 필요할까요? 할인 정책이 필요할 것입니다. 할인 정책중 금액할인 정책의 경우에는 어떤 데이터가 필요할까요? discountAmount(할인금액) 데이터가 필요할 것입니다. 그렇다면, 비율 할인 정책의 경우에는 어떤 데이터가 필요할까요? percentAmount(비율할인) 데이터가 필요할것입니다.

 

이전 포스팅의 요구사항에서 말했듯이 할인정책의 경우 영화별로 한가지만 지정이 가능합니다. 따라서 한시점에 discountAmount와 discountPercent중 하나의 값만이 사용될 수 있습니다.

 

xxxxxxxxxx
public enum MovieType {
    AMOUNT_DISCOUNT,
    PERCENT_DISCOUNT,
    NONE_DISCOUNT
}

그렇다면 어떠한 상태가 사용될지 어떻게 알 수 있을까요? 이를 결정하는것이 바로 MovieType이라는 enum 타입의 객체입니다. 이 MovieType에 따라서 AMOUNT_DISCOUNT일 경우 discountAmount가 사용되고, PERCENT_DISCOUNT인 경우 percentDiscount값이 사용될 것입니다.

 

이런식으로 객체가 포함해야할 데이터에 집중하여 설계하는 방식을 데이터 중심 설계라고 합니다.

 

 

 

2. 데이터 주도 설계의 단점

2.1 캡슐화 위반

캡슐화는 좋은 설계를 위한 도구 중 하나입니다. 좋은 설계란 변경에 용이한 설계입니다. 변경에 용이한 설계를 위해서는 자세한 구현은 내부로 숨기고 인터페이스를 통해 객체간의 상호작용을 하도록 하는것입니다. 즉, 캡슐화를 통해 내부구현을 숨김으로써 변경에 용이한 설계가 가능합니다.

 

하지만 앞선 예제의 데이터 주도 설계의 결과로 만들어진 Movie는 캡슐화를 위반합니다. 언뜻보아 내부의 상태에 접근하기 위해서 getter, setter(이하 접근자와 수정자)를 이용해야 하기 때문에 캡슐화를 한 것같지만, 전혀 내부의 구현을 캡슐화 하지 못합니다. 즉, 내부에 fee, title, runningTime, 등의 상태가 존재하는것을 외부에서도 알게 됩니다. 다시 말해, 과도한 접근자와 수정자 때문에 내부의 구현이 퍼블릭 인터페이스에 노출되게 됩니다 이는 바로 객체가 수행할 책임이 아니라, 상태에 초점이 맞추어졌기 때문입니다.

 

설계시, 협력에 대한 고민을 하지 않았기 때문에, 과도한 접근자와 수정자가 탄생하게 되었습니다. 이는 후에 객체가 어떤곳에 사용될지 알수가 없기 때문에, 최대한 많은 접근자와 수정자를 만들게 된 것입니다. 이렇게 접근자와 수정자에 과도하게 의존하는 상황을 추측에 의한 설계전략이라고도 합니다.

 

*결과적으로 데이터 중심 설계는 외부에 대부분의 구현이 노출되기 때문에 캡슐화의 원칙을 위반하게 됩니다.

 

 

결합도와 응집도

데이터 주도 설계의 단점인 높은 결합도와, 낮은 응집도에 대해서 알아보기전에 각각의 의미에대해 조금더 자세히 짚어보도록 하겠습니다.

결합도

결합도란 의존성의 정도를 나타냅니다. 즉 다른 모듈에 대해 얼마나 많은 지식을 알고 있는지를 나타냅니다. 어떤 객체의 내부 구현을 변경했을때 다른 모듈에 영향을 미치는 경우, 결합도가 높다고 표현합니다. 반면 퍼블릭 인터페이스를 수정했을 경우에만 다른 모듈에 영향을 미치는 경우 결합도가 낮다고 합니다.

응집도

응집도란 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타냅니다. 응집도가 높을때에는 요구사항의 변경을 반영하기 위해서 오직 하나의 모듈만 수정하면 됩니다. 반면 응집도가 낮은 경우, 요구사항에 의해 변경을 해야하는 부분이 여러 모듈에 분산되어있기 때문에, 여러 모듈을 수정해야 합니다.

 

2.2 높은 결합도

2.1의 결과로 내부 구현이 퍼블릭 인터페이스에 노출되며, 이 때문에 다른 객체들과 강하게 결합되게 됩니다. 이때문에 객체의 내부 구현이 변경될 때 이 인터페이스에 의존하는 모든 객체들이 함께 변경되게 됩니다.