12일차 - 변경될 가능성이 있는 클래스를 찾아라

2023.08.12 SAT

140p ~ 155p

 

11일차 내용 ⬇️

2023.08.11 - [개발 서적 기록/오브젝트_조영호] - 11일차 - 책임 주도 설계로 전환하기

11일차 - 책임 주도 설계로 전환하기

---

여러 대안이 존재할 때는, 응집도와 결합도를 고려하라

책임을 할당할 때는, 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것이 첫번째 원칙이다.

( 이것이 INFORMATION EXPERT 패턴이다. )

 

하지만, 실제로 프로젝트를 설계하다보면, 여러 대안을 고려하게된다.

이때는 객체에 책임을 할당할 때 항상 고려해야하는 높은 응집도와 낮은 결합도를 적용하면 된다.

여러 대안 중에 높은 응집도와 낮은 결합도를 얻을 수 있는 설계를 선택해야한다.

( 이것이 LOW COUPLING 패턴, HIGH COHESION 패턴이다. )

 

관련될 필요가 있는 객체가, 객체 생성의 책임을 가져라

어떠한 객체(A)를 생성해야할 때, 그 객체(A)와 연결되거나 관련될 필요가 있는 다른 객체(B)가 해당 객체(A)를 생성할 책임을 가져야한다.

( 이것이 CREATOR 패턴이다. )

생성될 객체(A)에 대해 잘 알고 있어야하는 객체(B)는, 혹은 그 객체(A)를 사용해야하는 어떤 객체(B)는, 어떤 방식으로든 생성될 객체(A)와 연결되는, 서로 결합되기 때문이다.

 

그래서, 객체를 생성할 다른 객체는 아래와 같은 조건을 최대한 많이 만족하는 객체다.

- B가 A 객체를 포함하거나 참조한다.

- B가 A 객체를 기록한다.

- B가 A 객체를 긴밀하게 사용한다.

- B가 A 객체를 초기화하는데 필요한 데이터를 가지고 있다. ( 즉, B는 A에 대한 INFORMATION EXPERT다. )

 

위 조건을 많이 만족하는 두 객체는, 가장 적합하게 결합되므로 낮은 결합도를 유지할 수 있다.

 

변경될 가능성이 있는 클래스를 찾아라 : 인스턴스 변수가 초기화되는 시점을 확인하라

응집도가 높은 클래스는 인스턴스를 생성할 때, 모든 속성을 함께 초기화한다.

하지만, 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화한다.

 

따라서, 함께 초기화되는 속성을 기준으로 코드를 분리해야한다.

 

영화에 대한 할인 조건을 나타내는 DiscountCondition 클래스가 있다고 예를 들어보자.

이 DiscountCondition 클래스는 기간에 따른 할인과 순서에 따른 할인 으로 두 종류 중 하나로 객체를 생성한다.

이때, 기간에 따른 할인 종류의 DiscountCondition 객체로 생성된다면, DiscountCondition 클래스의 순서 필드는 초기화되지 않는다.

순서에 따른 할인 종류의 DiscountCondition 객체로 생성된다면, DiscountCondition 클래스의 시작일, 종료일 등의 기간을 나타내는 필드는 초기화되지 않는다.

따라서, DiscountCondition 클래스는 기간에 따른 할인을 적용하는 클래스와 순서에 따른 할인을 적용하는 클래스로 분리되어야한다.

 

변경될 가능성이 있는 클래스를 찾아라 : 메서드가 인스턴스 변수를 사용하는 방식을 확인하라

모든 메서드가 객체의 모든 속성을 사용한다면, 클래스의 응집도는 높다고 볼 수 있다.

하지만, 메서드가 사용하는 속성에 따라서 그룹이 나뉜다면, 클래스의 응집도는 낮아진다.

 

따라서, 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해, 클래스의 응집도를 높여야한다.