Ch02. 절차적인 설계 개선하기 - 변경과 의존성

절차적인 설계의 문제점

• 데이터를 구현한 코드를 수정에 취약하다.
• 절차적인 방식에서는 여러 프로세스가 데이터를 공유하기 때문에 데이터가 바뀌면 데이터에 의존하는 하나 이상의 프로세스가 동시에 수정되는 문제가 발생한다.
  • 조합조건이 추가가 된다면, 할인 조건을 처리하는 프로세스가 수정이 되어야 한다.
    • 조합 조건이 추가가 되어 데이터인 DiscountCondition이 수정이 되어야 하고, 그 영향으로 데이터를 사용하는 프로세스가 수정이 되어야 한다.
  • 코드개선 작업 진행 시에도 프로세스가 수정이 되어야 한다(ex. 시간 범위 수정)
    • DiscountCondition의 startTime, endTime 필드를 명시적인 시간 범위를 지정하는 interval이라는 필드로 변경 시, 이를 사용하고 있는 프로세스에서도 수정이 되어야 한다.

데이터를 수정할 때마다 이 데이터를 사용하는 프로세스도 함께 수정해야 한다는 문제점이 존재한다.

 

 

의존성

의존성

의존성 코드

• A와 B라는 모듈이 있을 때, A가 B를 사용하면 A가 B에 의존한다고 한다.
  • B가 변경될 때, A가 변경될 수 있다는 가능성이 있다.
• 의존성이란 다른 코드가 수정될 때 함께 수정될 수 있는 가능성을 말한다.
• 클래스 안에 포함된 다른 클래스의 텍스트는 의존성을 의미한다.

변경성과 의존성과의 관계

변경의 방향과 의존성의 방향은 반대

절차지향에서의 프로세스와 데이터 관계

• 변경 방향과 의존성의 방향은 반대이다.
• 변경과 의존성은 서로 관련이 있기 때문에 변경하기 쉬운 설계를 만들기 위해서는 의존성을 통제해야 한다.
• 절차적인 방식에서는 프로세스와 데이터를 별도의 모듈로 구현하는데, 분리된 프로세스 모듈이 데이터 모듈에 의존하게 된다. 프로세스는 데이터에 의존하고 변경의 방향은 의존성과 반대이기 때문에 데이터가 수정될 때 프로세스로 변경의 영향이 전파될 수밖에 없다.

기존 DiscountCondition 문제점 

기존 DiscountCondition 문제점

• 데이터가 수정되더라도 프로세스 쪽으로 영향이 전파되지 않도록 private를 이용해 캡슐화 작업을 진행하였지만, Getter/Setter를 통해 내부의 데이터를 그대로 노출하고 있기 때문에 문제가 있다.
• 데이터를 설계할 때 데이터가 사용되는 문맥을 전혀 고려하지 않았기 때문에 발생하는 문제이다.
  • 데이터가 어떤 문맥에서 어떻게 사용될지 모르는 상황에서 데이터를 사용 가능하게 만드는 유일한 방법은 모든 경우에 사용될 수 있도록 내부의 정보를 그대로 드러내는 것밖에 없다.
  • 따라서 Getter/Setter 메서드를 만들어 내부의 정보를 그대로 노출시킬 수밖에 없었다.
  • 이처럼 문맥과 무관하게 어떤 상황에서도 데이터를 사용 가능하도록 내부의 데이터를 그대로 드러내는 설계 방식을 추측에 의한 설계 방식이라고 한다.

추측에 의한 설계 방식 단점

추측에 의한 설계 방식 단점1

추측에 의한 설계 방식 단점2

• 추측에 의한 설계 방식은 데이터를 언제/어떻게 사용될지 문맥을 전혀 고려하지 않았기 때문에 어떤 클래스가 이 데이터를 사용하는지 파악하기 힘들다.
• 추측에 의한 설계 전략에 따라 모든 경우에 접근 가능하도록 만들어야 하므로 다른 클래스가 사용하는 방식을 컨트롤하기 쉽지 않다.

 

따라서 수정하기 쉬운 설계를 만들기 위해서는 데이터 변경으로 인한 파급 효과를 막는 것이 핵심이다. 문제의 근본 원인이 데이터와 프로세스를 별도의 모듈로 분리했기 때문이라면 이를 해결하기 위해서는 데이터와 프로세스를 하나로 합치는 것이다.(데이터와 프로세스를 하나의 모듈에 합침) 이러한 데이터와 프로세스의 통합이 객체지향의 가장 기본적인 개념이다.