5. 응집도 - 흩어져 있는 것들

내용

---

• 응집도?

  • 모듈 내부에 있는 데이터와 로직 사이의 관계가 얼마나 강한지 나타내는 지표

  • 응집도가 높으면, 변경하기 쉬우며 바람직한 구조

  • 응집도가 낮으면, 변경시 문제가 생길 가능성이 높음

static 메서드 오용

• static method는 데이터를와 로직이 서로 다른 클래스에 작성되어있게 만들기 마련

• 왜 static 메서드를 사용하나?

  • 절차 지향 언어에서는 데이터와 로직이 따로 존재하도록 설계

  • 즉 객체 지향 언어에서 절차 지향 방법을 사용하려고 하기 때문

• 어떨 때 static 메서드를 사용하면 좋을까?

  • 로그 출력 전용 메서드

  • 포맷 변환 전용 메서드

초기화 로직 분산

• 생성자를 private으로 반들고, 대신 목적에 따라 팩토리 메서드를 만들어라

• 생성 로직이 너무 많아지면 팩토리 클래스를 고려해봐라

범용 처리 클래스

• common , util 이라는 이름 자체를 쓰지말자.

  • 범용?

    • 범용적으로 사용하고 싶은 로직을 모아둠.

    • 서로 관련 없는 로직들이 모여저 있을 가능성이 높다

• 횡단 관심사

  • 다양한 상황에서 넓게 활용되는 기능

  • 예시

    • 로그 출력,

    • 오류 확인

    • 디버깅

    • 예외 처리

    • 캐시

    • 동기화

    • 분산 처리

결과를 리턴하는 데 매개변수 사용하지 않기

class ActorManager {

// 게임 캐릭터 위치를 이동
	void shift (Location location, int shift X, int shift Y) {
		location.x += shift X;
		location.y += shift Y;
	}
}

• 데이터 조작 대상 location 과 조작 로직 ActorManager 가 각자 다른 클래스에 있음.

  • 즉 응집도가 낮은 구조

    • 응집도가 낮으면 중복을 만든다.

매개변수가 너무 많은 경우

• 매개변수가 많다?

  • 많은 기능을 처리하고 싶다.

  • 그러면 처리할 게 많아지면서 로직이 복잡해지거나 중복 코드가 생길 가능성이 높아진다.

• 의미 있는 단위는 모두 클래스로 만들어라

  • 매개변수가 많으면 데이터 하나하나 매개변수로 다루지말고, 그 데이터를 인스턴스 변수로 갖는 클래스를 만들고 활용하도록 설계를 변경해보자

메서드 체인

• 데메테르의 법칙

  • 사용하는 객체 내부를 알아서는 안된다는 법칙

  • 메서드 체인은 내부 구조를 돌아다닐 수 있는 설계이고, 이는 위 법칙을 위반하는 설계 이다.

• 묻지 말고, 명령하기

  • Tell, Don't Ask

  • 다른 객체의 내부 상태(변수) 를 기반으로 판단하거나 제어하려고 하지 말고, 메서드로 명령해서 객체가 알아서 판단하고 제어하도록 설계하라는 의미

정리

---

• static 메서드 오용하지 말자

• common, util 같은 클래스 만들지 말자

• 의미있는 변수는 모두 클래스로 만들자

참고

---

• https://product.kyobobook.co.kr/detail/S000202521361