[오브젝트] 클래스를 분리해야할 때

변경에 있어서 자유롭지 못 한 클래스는 분리해야한다.

문제는 클래스 안에서 변경의 이유를 찾는 것이 생각보다 어렵다는 점이다.

 

코드를 통해 변경의 이유를 파악할 수 있는 첫 번째 방법은 인스턴스 변수가 초기화 되는 시점을 살펴보는 것이다.

응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화하는 반면, 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고 일부는 초기화되지 않은 상태로 남겨진다.

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

 

코드를 통해 변경의 이유를 파악할 수 있는 두 번째 방법은 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것이다.

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

속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야한다.

 

코드를 분리한 후 응집도를 높였지만, 결합도가 높아지지 않았는지를 추가로 확인해야한다.

기존에는 하나의 클래스와 결합이 맺어져 있었지만, 분리시킨 후 결합도가 증가했다면 다형성을 통해 분리하는게 좋다.

객체의 역할이 무엇이였는지 다시 확인하고, 상위 클래스가 구현에 대해서는 알지 못 하고 오직 역할에 대해서만 결합되도록 의존성을 제한해야한다.

다형성을 활용해 역할을 구현하기 위해서는 추상클래스와 인터페이스를 사용할 수 있다.

역할을 대체할 클래스들 사이에서 구현을 공유해야 한다면 추상클래스를, 공유할 필요 없이 책임만 정의하고 싶다면 인터페이스를 사용하면 된다.

 

즉 하나의 클래스가 여러 타입의 행동을 구현하고 있는 것 처럼 보인다면 클래스를 다형성을 이용해 책임을 분산시키자.

그럼 우리는 변경과 확장에 유연하게 대처할 수 있는 설계를 얻을 수 있다.

우리가 지향해야할 코드는 오늘의 요구기능을 모두 만족하며 내일 변경을 수용할 수 있는 코드이다.