5. 책임 할당하기 - 5

🐿️  4장 초반에 개발한 데이터 중심 설계를 리팩토링하는 과정을 통해 리팩토링으로 책임을 할당하는 방법의 장점을 설명

🗣️ 책임 주도 설계의 대안

 

1. 메서드 응집도

중요한 것은 메서드의 이름과 메서드 몸체의 의미적 차이

 

객체로 책임을 분배할 때 가장 먼저 할 일:

메서드를 응집도 있는 수준으로 분해하는 것

→ 긴 메서드를 작고 응집도 높은 메서드로 분리하면 각 메서드를 적절한 클래스로 이동하기가 더 수월해짐

 

작고, 명확하며, 한 가지 일에 집중하는 응집도 높은 메서드는 변경 가능한 설계를 이끌어 내는 기반이 된다.

이런 메서드들이 하나의 변경 이유를 가지도록 개선될 때 결과적으로 응집도 높은 클래스가 만들어진다.

 

 

2. 객체를 자율적으로 만들자

어떤 메서드를 어떤 클래스로 이동시켜야 하는가

: 메서드가 사용하는 데이터를 저장하고 있는 클래스로 메서드를 이동시킨다.

 

어떤 데이터를 사용하는지를 가장 쉽게 알 수 있는 방법

: 메서드 안에서 어떤 클래스의 접근자 메서드를 사용하는지 파악

 

isDiscountable() 메서드를 ReservationAcency class에서 DiscountCondition class로 옮김으로써 모든 접근자 메서드를 제거함

→ DiscountCondition class 내부 구현을 캡슐화함 + 할인 조건을 계산하는 데 필요한 모든 로직이 DiscountCondition class에 모임으로 인해 응집도 높아짐

 

ReservationAgency class는 내부 구현을 노출하는 접근자 메서드를 사용하지 않고 메시지를 통해서만

DiscountCondition과 협력함

→ 낮은 결합도 유지