Getter를 무분별하게 사용하면 안되는 이유

자바 빈 규약이란 자바에서 재사용 가능한 소프트웨어 컴포넌트를 만들기 위해 정한 규칙을 말합니다.

다음과 같은 자바 빈 규약이 있습니다.

 

1. 기본 생성자를 반드시 가져야 한다

2. 빈이 패키지화 되어 있어야 한다

3. 멤버 변수의 접근자는 private으로 선언한다

4. 멤버 변수에 접근하기 위한 public 접근자인 getter/setter 메소드가 존재해야 한다

 

여기서 자바 빈 규약의 4번 예시처럼 getter/setter를 사용하여 외부에서 데이터를 가져오고 변경할 수 있습니다.

하지만 setter의 경우 외부에서 객체의 필드를 마음대로 바꿀 수 있으며 setter라는 메소드가 어떠한 이유로 필드의 값을

변경했는 지를 파악하기 어렵습니다. 따라서 필드의 값을 변경해야 한다면 의미있는 메소드명을 사용하여 명확하게 나타내고

setter 사용은 지양해야 합니다.

 

하지만 getter는 외부에서 데이터를 변경하는 것도 아닌데 왜 사용을 지양해야 한다는 것인지 이해하기 조금 어려웠습니다.

이번 글에서는 하나의 기능을 구현해보며 getter를 사용했을 때와 사용하지 않았을 때의 차이점에 대해 알아보겠습니다.

주문 가격의 총합 구현 

구현하고자 하는 기능은 여러 주문 가격의 총합을 구하는 것입니다. 이때 나이가 20살이 넘지 않는다면 1000원 할인을 적용해야

합니다. Member에는 이름/나이가 있고, Order에는 Member와 가격 정보, Orders에는 주문 목록이 있습니다.

Getter 사용했을 때

Member

public class Member {

    private String name;
    private int age;

    public Member(final String name, final int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

Order

public class Order {

    private Member member;
    private int price;

    public Order(final Member member, final int price) {
        this.member = member;
        this.price = price;
    }

    public Member getMember() {
        return member;
    }

    public int getPrice() {
        return price;
    }
}

Orders

public class Orders {

    private List<Order> orders;

    public Orders(final List<Order> orders) {
        this.orders = orders;
    }

    public List<Order> getOrders() {
        return orders;
    }
}

OrderService

public class OrderService {

    public int calculateTotalPrice(final Orders orders) {
        int totalPrice = 0;

        for (Order order : orders.getOrders()) {
            Member member = order.getMember();
            int price = order.getPrice();
            int age = member.getAge();

            if (age < 20) {
                price -= 1000;
            }

            totalPrice += price;
        }

        return totalPrice;
    }
}

 

OrderService에 주문과 관련된 비즈니스 로직을 구현 하였습니다. 이때 OrderService는 전체적인 비즈니스 로직의 흐름을 

알려주는 것보다는 상세한 구현에 가깝습니다. order에서 회원 정보를 가져온 후 나이를 확인하고 할인을 적용하고 값을 더하고 ..

 

물론 이와 같은 방식도 효율적일 수 있습니다. 도메인에서 get 메소드로 가져온 다음 OrderService에서 구현하는 것이 

전체 로직이 한 메소드 안에 있으니 클래스를 여기저기 옮겨 다니지 않고 바로 확인할 수 있기 때문입니다.

로직이 복잡하지 않고 간단할 때는 위와 같은 방식이 더 효율적일 수도 있다고 생각합니다.

 

하지만 문제는 로직이 복잡해질 때 발생합니다.

OrderService에 calculateTotalPrice 메소드 뿐만 아니라 여러 메소드가 추가되고 각각의 구현도 복잡해진다면

유지보수가 굉장히 힘들어질 수 있는 코드가 될 수 있기 때문입니다.

Getter 사용하지 않았을 때

이제 위에서 구현했던 것을 getter를 사용하지 않도록 리팩토링 해보겠습니다.

여기서 중요한 것은 도메인으로부터 get 메소드로 가져와 OrderService에서 구현하는 것이 아니라 필요한 해당 필드가 있는

객체에 요청을 하는 것입니다.

Member

public class Member {

    private String name;
    private int age;

    public Member(final String name, final int age) {
        this.name = name;
        this.age = age;
    }

    public boolean isAdult() {
        return age >= 20;
    }
}

나이가 20살이 넘는지를 Member 객체로부터 get 메소드로 가져와서 확인하는 것이 아니라 해당 객체에 요청하여

20살이 넘는지를 확인합니다.

Order

public class Order {

    private Member member;
    private int price;

    public Order(final Member member, final int price) {
        this.member = member;
        this.price = price;
    }

    public int addPrice(final int totalPrice) {
        return totalPrice + price;
    }

    public boolean isDiscountCondition() {
        return !member.isAdult();
    }

    public void discount() {
        price -= 1000;
    }
}

가격을 총합을 구하기 위해서 각 Order의 price를 모두 get 메소드로 가져온 후 합을 구했었지만 이번에는 가격의 총합을

매개변수로 받은 후 해당 객체의 price를 더한 후 반환하도록 요청합니다.

할인 여부를 판단하기 위해서 나이가 20살이 넘는지를 확인했던 Member에 요청을 하여 결과를 반환합니다.

할인을 적용하기 위해서 해당 객체의 price에 1000원을 뺀 가격을 반환합니다.

Orders

public class Orders {

    private List<Order> orders;

    public Orders(final List<Order> orders) {
        this.orders = orders;
    }

    public int calculateTotalPrice() {
        int totalPrice = 0;
        for (Order order : orders) {
            if (order.isDiscountCondition()) {
                order.discount();
            }

            totalPrice = order.addPrice(totalPrice);
        }

        return totalPrice;
    }
}

Orders도 마찬가지로 get 메소드를 이용해 모든 주문을 가져온 후 처리하지 않고 해당 필드를 가진 Orders 객체에

요청할 수 있도록 calculateTotalPrice 메소드를 구현합니다.

OrderService

public class OrderService {

    public int calculateTotalPrice(final Orders orders) {
        return orders.calculateTotalPrice();
    }
}

이제 get 메소드를 없애고 구현한 OrderService를 살펴보겠습니다. 이렇게 객체로부터 필드 정보를 get 메소드로

가져와서 구현하지 않고 객체에 요청하는 방식은 로직이 더 복잡해지면 복잡해질 수록 힘을 발휘한다고 생각합니다.

 

OrderService에 비즈니스 로직이 많아지더라도 상세한 구현은 해당 필드를 가진 객체에 위임하였기 때문에

메소드만 보고도 전체적인 비즈니스 로직의 흐름을 파악하기 쉽기 때문입니다.

무분별하게 Getter 사용하면 안되는 이유

위에서 할인을 적용한 주문 가격의 총합을 구하는 2가지 방식에 대해 설명하였는데 다시 정리해보겠습니다.

 

getter를 사용하면 외부에서 데이터를 변경하는 것이 아니기 때문에 막 사용해도 괜찮다고 생각할 수도 있지만

객체지향적인 설계와 멀어질 수 있습니다. 해당 필드를 가진 객체로부터 get 메소드로 데이터를 받아와서 처리하는 것이 아닌

해당 객체에 요청을 하여 처리할 수 있도록 해야합니다.

 

이 내용은 이전에 작성한 글에서도 확인할 수 있는데 Layered Architecture에서 Service에는 상세한 구현이 아닌

전체적인 비즈니스 로직의 흐름을 알 수 있도록 하는 것이 좋은 방법이라고 생각한다고 하였습니다.

이렇게 설계할 수 있도록 하는 방법 중 하나가 무분별하게 Getter를 사용하지 않는 것이라고 생각합니다.

문제가 많은 Layerd Architecture를 살려보자

하지만 get 메소드를 아예 사용하지 않고 구현을 하기에는 어려울 수 있습니다. 아예 사용을 금지해야 한다는 것은

아니지만 사용을 지양하는 방향으로 가되 꼭 필요한 경우에만 선택적으로 사용할 수 있도록 해야 한다고 생각합니다.

Getter를 사용하는데 외부에서 필드를 수정할 수 있다?

참고로 getter를 사용하더라도 외부에서 데이터를 변경할 수 있는 경우도 있습니다.

public List<Order> getOrders() {
    return orders;
}

public void updateOrders(final Orders orders, final Order order) {
    List<Order> totalOrders = orders.getOrders();
    totalOrders.add(order, 10000));
}

위와 같이 Collection 인터페이스를 사용할 경우 get 메소드를 사용하더라도 외부에서 데이터를 변경할 수 있습니다.

 

따라서 꼭 get 메소드가 필요한 경우이면서 Collection 인터페이스를 사용하는 경우에는 다음과 같이 외부에서 변경할 수 없도록

해야 합니다.

public List<Order> getOrders() {
    return Collections.unmodifiableList(orders);
}

참고한 자료

getter를 사용하는 대신 객체에 메시지를 보내자