Java 클래스 설계 안전하게 잘 하기 (feat. 응집도)

지난 포스팅 Java 클래스 설계 안전하게 잘 하기 편에서는 클래스 설계와 관련하여 다음 내용들을 살펴봤었는데요,

1. 생성자를 통해 정상적인 값 설정하기
2. 변수를 불변으로 만들어서 예상하지 못한 동작 예방하기
3. 불변을 변경해야 하는 경우, 새로운 인스턴스를 생성하기
4. 메서드 매개변수와 지역 변수도 불변으로 만들기
5. 메서드에 잘못된 값의 전달을 예방하기

 

이번 포스팅에서는 응집도를 기준으로 클래스 설계와 관련된 내용을 정리해 보겠습니다.

응집도는, '클래스 내부에 있는 데이터와 로직 사이의 관계가 얼마나 강한지 나타내는 지표' 로 정의합니다.

 

 

1. static 메서드 오용

static 메서드는 인스턴스를 생성하지 않고 사용할 수 있다는 편리함이 있지만, 다른 한편으로는 응집도가 낮아질 수 있습니다.

static 메서드(add)는 인스턴스 변수(money)를 사용할 수 없기 때문에, 어떠한 메서드를 static으로 만든 시점에서부터 이미 데이터와 데이터를 조작하는 로직 사이에 괴리가 생기게 됩니다. 이로 인해 당연히 응집도가 낮아질 수밖에 없습니다.

 

다양한 부수 효과로부터 클래스가 스스로를 보호할 수 있게, 데이터와 로직을 모아 응집도가 높은 구조로 설계하는 것이 객체 지향 설계의 기본 원칙이라고 할 수 있습니다.

 

따라서 응집도를 높이려면, '인스턴스 변수'와 '인스턴스 변수를 사용하는 로직'을 동일한 클래스에 만들어야 합니다.

 

사실 위와 같은 메서드도 인스턴스 변수인 discountRate를 사용하지 않는 형식이기 때문에 static 메서드와 동일한 문제를 가지게 되어 응집도를 낮출 수 있습니다.

(위 메서드에서 static 키워드를 붙여도 아무 문제 없이 동작합니다.)

 

따라서 이전 포스팅에서 살펴본 것처럼, 적절한 클래스 (Money 등)에서 계산하도록 설계하면 해결할 수 있습니다.

 

1.1 static 메서드는 그럼 언제 사용해야 좋을까요?

응집도의 영향을 받지 않는다면, statis 메서드를 사용해도 괜찮다고 합니다.

예를 들어 로그 출력, 오류 확인, 디버깅, 예외 처리 등의 기능에서는 static 메서드를 사용해도 괜찮을 것 같습니다.

그리고 Java에서 static 메서드를 구현해놓은 가장 대표적인 클래스는 Collections, Arrays 등등의 복수형 명사를 지닌 클래스입니다.

(위 클래스들은 모든 메서드들이 statis 으로 구현되어 있습니다.)

기본적으로 객체를 생성할 수 없는 클래스의 네이밍은 보통 복수형 명사로 짓습니다. [Effective Java Item 68]

 

따라서 Collections, Arrays 등등 객체 생성은 필요 없고 다양한 메서드를 제공하는 클래스는 static 메서드를 사용합니다.

 

 

2. 초기화 로직 분산

초기화 로직이 분산되어도 응집도가 낮은 구조가 되어 버리는 경우가 발생할 수 있습니다.

예를 들어 쇼핑몰 사이트에서 포인트를 값 객체로 설계한 GiftPoint 클래스를 살펴볼게요.

 

 

표준 회원의 경우 3000 포인트를 제공하고, 프리미엄 회원의 경우 10000 포인트를 제공한다고 하면 다음과 같습니다.

생성자가 public 이기때문에 의도하지 않은 용도로 사용될 수 있습니다.

표준 회원, 멤버십 회원 외의 회원 유형이 늘어날수록 의도하지 않은 용도로 사용할 확률이 높아지게 됩니다.

 

이러한 경우, private 생성자와 팩토리 메서드를 사용하여 목적에 맞게 초기화하는 전략을 사용할 수 있습니다.

위와 같은 팩토리 메서드를 통해 메서드명만 보고도 어떤 유형의 회원인지 바로 확인이 가능하고, 

포인트 변경이 필요하더라도 GiftPoint 클래스만 확인하여 간단히 변경할 수 있습니다.

 

 

3. 매개변수가 너무 많은 경우

매개변수가 너무 많은 경우 응집도가 낮아지기 쉽습니다.

예를 들어, RPG 같은 게임에서 MP(매직 포인트)와 관련하여 다음과 같은 사양이 있다고 가정합니다.

• 마법을 사용하면 매직포인트가 일정량 감소
• 회복 아이템 등을 사용하면 매직포인트가 일정량 회복
• 매직포인트는 최댓값을 가짐
• 매직포인트는 최댓값까지만 회복이 가능
• 일부 장비는 매직포인트 최댓값을 높이는 효과

위 메서드는 많은 매개변수를 받아 실수로 잘못된 값을 대입할 가능성이 높고, 회복 이외의 매직포인트 최댓값 증가량 등 많은 기능을 처리하기 위해 매개변수가 많아지고 있습니다.

 

따라서 매개변수가 많아지는 문제를 피하려면, 개념적으로 의미 있는 클래스를 만들어야 합니다.

 

핵심은 매직포인트 입니다. 이와 관련된 값들을 인스턴스 변수로 가지고, 관련 로직을 작성합니다.

 

매개변수가 많을 경우 데이터 하나하나를 매개변수로 다루기보다는, 해당 데이터를 인스턴스 변수로 가지는 클래스를 만들고 이를 활용하는 방식으로 설계하여 응집도를 높일 수 있습니다.

 

 

4. 메서드 체이닝

상세한 로직을 호출하는 쪽에서 구현

물론 위와 같이 작성하는 일은 거의 없겠지만, getter 등을 통해 메서드 체이닝으로 클래스 내부의 깊은 요소에 접근하는 코드는 생각보다 자주 볼 수 있는 패턴의 코드입니다.

 

하지만 위와 같은 코드도 응집도를 낮출 수 있어 권장하지 않는 방법인데요, armor에 할당하는 코드를 위 메서드뿐만 아니라 다른 곳에서도 중복으로 작성될 가능성이 존재하고, 이는 요구 사항이 변경되면 해당 요소에 접근하고 있던 모든 코드를 확인하고 수정해야 하는 문제점이 발생할 수 있기 때문입니다. 

이와 관련하여 디미터의 법칙이라는 개념이 존재합니다. (사용하는 객체 내부를 알아서는 안된다는 법칙, 참고)

 

객체 지향 설계에서 사용되는 '묻지 말고, 명령하기(Tell, Don't Ask)' 라는 방법이 존재합니다.

 

상세한 로직을 호출되는 쪽에서 구현

위처럼 상세한 로직은 호출하는 쪽이 아닌, 호출되는 쪽에서 구현합니다.

 

 

참고자료

• 내 코드가 그렇게 이상한가요?