[엘레강트 오브젝트] 2.2 최소한 뭔가는 캡슐화하세요

이 내용은 엘레강트 오브젝트 를 읽으면서 정리한 내용을 포함하고 있습니다.

다음 목차로 진행합니다.

• 캡슐화
• 연습해보기
• 실습
• 정리

캡슐화

• 프로퍼티가 없는 클래스는 객체지향 프로그래밍에서 정적 메소드와 유사
• 아무것도 캡슐화하지 않는 방식은 바람직하지 않다.
  • 이러한 클래스들은 아무런 상태와 식별자도 가지지 않고 오직 행동만을 포함한다.

연습해보기

• 실행으로부터 인스턴스 생성을 고립시켜야 한다.
  • 오직 생성자에서만 new 연산자를 허용해야 한다.
• 좌표가 없는 객체는 무언가를 캡슐화해야 한다.
  • 객체는 자기 자신을 식별할 수 있도록 다른 객체들을 캡슐화해야 한다.

실습

로또 예를 들어서 확인해보도록 하겠다.

• 로또 6개의 번호 중 하나의 번호를 책임지는 객체가 있다.

아래와 같은 객체는 필요할까?

• 해당 객체는 식별자나 상태를 가지지 않고 반환만 한다.

public class Lotto {

    public int converter(final String number) {

        return Integer.parseInt(number);
    }
}

• 해당 객체를 통해서 얻을 수 있는 것은 문자로 입력받은 로또 번호를 숫자로 변환해주는 것 밖에 없다.
• 당첨 로또 번호와 비교하기 위해서는 어떻게 해야 할까?
  • 해당 객체는 식별자(좌표)를 갖고 있지 않기 때문에 호출하는 외부에서 비즈니르 로직을 갖고 있어야 한다.
  • 로또 번호 객체라고는 하지만 그 책임을 다하지 않고 있다.
  • 또한 로또 번호는 1 ~ 45번 사이의 번호를 갖고 있어야 하는데, 이러한 검증 로직 또한 밖에서 로직을 가지고 있어야 한다.
  • 역시 그 책임을 다하지 않고 있다.
  • 그렇다면 이 로또 객체는 책임을 다하고 있는 객체인지 의심해봐야 한다.
• 해당 객체가 식별할 수 있는 좌표(로또 번호)를 갖고 있어야 한다.

가장 큰 문제는 핵심 비즈니스 로직인 로또 당첨 번호 매칭과 유효성 체크 로직이 분리되어 있다는 것이다.

다음과 같이 변경해보겠습니다.

public class Lotto {

    private static final int MIN = 1;
    private static final int MAX = 45;

    private final int number;

    public Lotto(final int number) {

        validate(number);
        this.number = number;
    }

    private void validate(final int number) {

        if (number < MIN || number > MAX) {
            throw new IllegalArgumentException("로또 숫자는 1 ~ 45 사이여야 합니다.");
        }
    }

    public static Lotto from(final String number) {

        return new Lotto(Integer.parseInt(number));
    }

    ...
}

이제 로또의 객체가 책임지는 역할이 분명해보입니다.

• 사용자는 입력을 숫자 또는 문자열로 받아서 처리한다.
  • 문자열로 받았다면 숫자로 변환해준다.
• 로또 숫자는 1 ~ 45 까지 중에 값을 책임지고 검증해준다.
  • 외부에서 검증 로직을 갖고 있을 필요가 없어서 응집도가 높아진다.
• 해당 객체는 추후 당첨 로또 번호와 비교시 책임을 질 3수 있다.

정리

• 메소드만 있는 클래스들은 아무런 상태와 식별자도 가지지 않고 오직 행동만을 포함한다.
  • 멤버변수가 없는 클래스는 정적 메소드와 차이가 없으며, 책임을 지는 객체가 아니다.
• 객체는 자기 자신을 식별할 수 있도록 다른 객체들을 캡슐화해야 한다.