[객체지향 생활체조 원칙] 규칙 7. 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다

2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다

 클래스의 인스턴수 변수를 제한하라는 지침이다. 여기서의 인스턴수 변수는 원시타입, 또는 컬렉션과 같이 기본 또는 자료구조형의 변수를 의미한다.

숨은 의미

 클래스의 인스턴수 변수는 클래스가 관리하는 '상태' 를 의미한다. 클래스의 상태는 클래스의 정체성을 나타내는 요소이다. 이 상태의 종류가 많다는 것은 클래스가 여러 종류의 정체성을 가지고 설계되었다는 것을 의미한다.

 

 이 지침은 원칙의 세 번째 지침인 '모든 원시값과 문자열을 포장한다' 의 내용과 통한다. 세 번째 지침은 상태에 도메인적 의미를 부여하라는 가이드라고 할 수 있다. 이 일곱번째 지침에서는 의미를 갖는 상태를 어떻게 관리하는 것이 좋은지에 대한 내용을 이야기하고 있다.

예시

class Name {
    String firstName;
    String lastName;
    // ... 성과 이름에 대한 기능
}

public class Name {
    FirstName firstName;
    LastName lastName;
}

class FirstName {
    String name;
    // ... 이름에 대한 기능
}

class LastName {
    String name;
    // ... 성에 대한 기능
}

 위 코드의 경우 Name 이라는 클래스가 String 형태의 속성을 두 개 지니고 있다. 여기서 생각해 볼 점은 성, 이름 이라는 서로 다른 도메인 요소를 가지고 있는 상태가 동일한 String 형태로 한 클래스에서 관리된다는 점이다. 이는 성 또는 이름이라는 도메인적 요소를 갖는 기능 (성, 이름이 갖는 역할과 책임)을 Name 클래스에서 모두 구현해야 함을 의미한다.

 

 아래 코드는 성과 이름을 각각 LastName, FirstName 이라는 클래스로 표현했다. 이제 성과 이름에 대한 특별한 동작을 각자 클래스에서 처리할 수 있게 되었다.

인스턴스의 '수' 를 줄여라 - 클래스는 계층적인 분류로 설계해야 한다

 이 지침을 클래스의 '기능' 이라는 요소에 초점을 맞추어 생각하면, 앞서 언급한 내용과 같이 원시데이터의 '포장' 이라는 주제만을 보게 된다. 그런데 이는 앞서 다룬 '모든 원시값과 문자열을 포장한다' 지침의 내용과 큰 차이가 없다. 필자는 이 지침의 또 다른 의미를 클래스의 설계를 계층적으로 세워보라는 의미로 해석했다.

 

 Class 는 '분류' 라는 뜻을 가지고 있다. 클래스는 다른 클래스를 인스턴스 요소로 가질 수 있는데, 클래스간의 소유관계가 생기면 계층적 분류가 이루어진다.

<계층적 분류 전>

<계층적 분류 후>

 위 두 그림을 보면 맥락없이 나열된 첫 번째 설계보다 어떤 기준을 가지고 도메인적 요소를 관리하는 두 번째 설계가 비즈니스적 활용도가 높을 것이라는 것을 알 수 있다.

 

 클래스에 빗대어 보면 금융상품이라는 클래스는 7개의 인스턴스 변수를 가지고 있었으나, 두 번째 설계에서 4개의 인스턴스 변수를 가지게 되었다. 이 지침의 가이드라인에 따라 인스턴스의 수를 줄인 것이다.

마치며

 이 지침의 가장 이상적인 형태는 모든 클래스가 인스턴스의 개수가 한 개인 형태로 설계하는 모양새일 것이다. 분류를 세분화하는 것은 좋으나 오버엔지니어링은 부작용을 불러오기 마련이다. 도메인 요소들을 어떻게 묶고 구성할 것인지 그 설계에 대해 충분히 고민하여 클래스를 구성하고, 리팩토링 해보라는 지침으로 생각하면 좋을 것 같다.