item 16 : public 클래스에서는 public 필드가 아닌 접 근자 메서드를 사용하라

1. 퇴보한 클래스의 문제점

인스턴스 필드를 모아놓기만 하고 캡슐화가 이루어지지 않은 클래스는 객체 지향 설계에서 문제가 된다.

직접 필드에 접근하는 클래스는 API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식(객체의 상태가 항상 유효함을 보장하는 규칙)을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수적인 작업을 수행할 수 없다.
예시로 제시된 Point 클래스처럼, public 필드를 노출하는 클래스는 내부 구현에 쉽게 묶여버리기 때문에 캡슐화의 장점을 활용하지 못한다.

class Point {
    public double x; // 필드가 public으로 노출됨
    public double y; // 필드가 public으로 노출됨
}

public class Main {
    public static void main(String[] args) {
        Point point = new Point();
        
        // 외부에서 x와 y 필드에 직접 접근하고 수정할 수 있음
        point.x = 5.0;
        point.y = 10.0;

        System.out.println("X: " + point.x + ", Y: " + point.y);

        // 외부에서 필드에 임의로 잘못된 값도 설정 가능
        point.x = -999.0; // 이런 잘못된 값이 들어갈 수 있음
        System.out.println("X: " + point.x + ", Y: " + point.y);
    }
}

위 코드에서는 x와 y 필드가 public으로 노출되어 있어 캡슐화의 이점을 제공하지 못하며, 필드의 값을 제어할 수 없다.

Point 클래스에서 x와 y 필드가 public으로 선언되어 있다.
외부에서 point.x = 5.0;처럼 직접 접근하여 값을 변경할 수 있다.

2. 접근자와 변경자를 사용하는 캡슐화 방식

이러한 문제를 해결하기 위해, 필드를 private으로 감추고 public 접근자(getter)와 변경자(setter) 메서드를 사용하는 방식이 일반적으로 적용된다. 이를 통해 내부 표현 방식을 바꾸더라도 외부 API를 수정하지 않고 유지할 수 있다.

class Point {
    private double x; // 필드를 private으로 숨김
    private double y; // 필드를 private으로 숨김

    public double getX() {
        return x;
    }

    public void setX(double x) {
        if (x >= 0) {  // 유효성 검사: x는 0 이상이어야 한다
            this.x = x;
        } else {
            System.out.println("잘못된 값입니다.");
        }
    }

    public double getY() {
        return y;
    }

    public void setY(double y) {
        if (y >= 0) {  // 유효성 검사: y는 0 이상이어야 한다
            this.y = y;
        } else {
            System.out.println("잘못된 값입니다.");
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Point point = new Point();
        
        // 메서드를 통해 필드에 접근 (제어 로직을 통해 값이 설정됨)
        point.setX(5.0);
        point.setY(10.0);
        System.out.println("X: " + point.getX() + ", Y: " + point.getY());

        // 유효하지 않은 값을 넣으려 하면 제어 로직이 동작함
        point.setX(-999.0); // 잘못된 값이 들어갈 수 없음
        System.out.println("X: " + point.getX() + ", Y: " + point.getY());
    }
}

이런 방식을 사용하면 필드에 직접 접근하는 대신 메서드를 통해 필드에 접근하거나 변경할 수 있어, 필드의 값을 안전하게 관리할 수 있다.

3. 패키지 내부나 private 중첩 클래스에서는 필드를 노출해도 괜찮을 때가 있다

패키지-프라이빗 클래스나 private 중첩 클래스의 경우에는 데이터 필드를 노출하는 것이 큰 문제가 되지 않는다. 그 이유는 이 클래스들이 외부에서 직접 접근할 수 없는 제한된 영역에서 사용되기 때문이다.
패키지-프라이빗 클래스는 같은 패키지 내에서만 접근할 수 있는 클래스이다. 즉, 이 클래스를 사용하는 코드도 같은 패키지 내에서만 동작하므로, 클래스의 필드가 외부로 드러나도 크게 문제되지 않는다. 외부 패키지에서는 이 클래스와 그 필드에 접근할 수 없기 때문
private 중첩 클래스는 클래스 내부에서만 사용할 수 있는 클래스이다. 이 경우는 더 좁은 범위에서만 접근 가능하기 때문에, 필드를 공개하더라도 그 필드에 접근할 수 있는 코드는 매우 제한적이다. 그래서 굳이 getter/setter를 사용해 캡슐화할 필요가 없다는 의미이다.

왜 이런 상황에서 문제가 없을까?

일반적으로 객체 지향 프로그래밍에서는 캡슐화가 매우 중요합니다. 즉, 필드를 직접 노출하는 대신 메서드를 통해 접근해야 하는 것이 권장된다. 그런데 패키지-프라이빗 클래스나 private 중첩 클래스처럼 외부에서 접근할 수 없는 제한적인 클래스라면, 필드를 노출해도 문제가 되지 않는 경우가 있다.

캡슐화의 필요성 감소: 이런 클래스들은 외부에서 접근이 제한되어 있기 때문에, 굳이 복잡한 캡슐화 구조를 만들 필요 없이 필드를 직접 노출하는 것이 더 간단하고 효율적일 수 있다.
내부 구현에 묶이는 것이 괜찮다: 클라이언트 코드가 이 클래스에 의존하더라도, 어차피 패키지 내부에서만 동작하는 코드이므로 클래스의 내부 구현 방식이 외부 패키지 코드에 영향을 주지 않는다.

class OuterClass {
    private static class InnerClass {
        public int value; // 필드를 공개해도 외부에서 접근할 수 없음
    }

    public void test() {
        InnerClass inner = new InnerClass();
        inner.value = 5; // 내부에서는 자유롭게 필드에 접근 가능
    }
}

InnerClass는 private 중첩 클래스이므로, OuterClass 내부에서만 접근할 수 있다.
따라서 필드를 public으로 노출해도 외부에서 접근할 수 없으므로 문제가 되지 않는다.

4. `public` 클래스의 가변 필드 노출 문제

자바 플랫폼 라이브러리에도 이 규칙을 어긴 예시들이 있는데, 대표적으로 java.awt 패키지의 Point와 Dimension 클래스가 있다. 이런 클래스들은 성능 문제 등으로 인해 나쁜 예로 취급되며, 이러한 접근 방식을 따라하지 말아야 한다.

왜 필드를 노출하면 문제가 되나요?

필드를 public으로 노출하면, 외부에서 필드에 직접 접근하고 값을 변경할 수 있다.
이는 객체의 불변식(invariant)을 깨뜨릴 수 있으며, 예기치 않은 동작을 유발할 수 있다.
또한, 내부 구현을 변경하기 어렵게 만들고, 유효성 검사나 부가적인 로직을 추가하기 어렵게 만든다.

5. 불변 필드의 경우에도 노출은 피해야 한다

불변 필드라고 해서 public으로 노출하는 것이 항상 안전한 것은 아니다.
불변 필드라도 노출을 피해야 하는 이유
- 불변 필드는 값이 변경되지 않으므로 무결성 측면에서는 안전하다.
- 그러나 내부 구현을 숨길 수 없으며, 나중에 API를 수정하지 않고 내부 표현 방식을 변경할 수 없다.
- 또한, 필드를 읽을 때 부수적인 작업(예: 로그 출력, 접근 권한 확인)을 수행할 수 없다.

예시:

public final class Time {
    public final int hour;
    public final int minute;

    public Time(int hour, int minute) {
        // 유효성 검사
        if (hour < 0 || hour >= 24)
            throw new IllegalArgumentException("시간: " + hour);
        if (minute < 0 || minute >= 60)
            throw new IllegalArgumentException("분: " + minute);
        this.hour = hour;
        this.minute = minute;
    }
}

hour와 minute 필드를 public final로 선언하여 불변 필드로 노출하고 있다.
문제점:
- 내부 구현을 변경할 수 없다.
- 필드 접근 시 부가적인 로직을 추가할 수 없다.

개선된 코드

public final class Time {
    private final int hour;
    private final int minute;

    public Time(int hour, int minute) {
        // 유효성 검사
        if (hour < 0 || hour >= 24)
            throw new IllegalArgumentException("시간: " + hour);
        if (minute < 0 || minute >= 60)
            throw new IllegalArgumentException("분: " + minute);
        this.hour = hour;
        this.minute = minute;
    }

    public int getHour() {
        // 부가 로직 추가 가능
        return hour;
    }

    public int getMinute() {
        // 부가 로직 추가 가능
        return minute;
    }
}

필드를 private final로 변경하고 getter 메서드를 제공한다.
장점:
- 나중에 내부 구현을 변경하더라도 외부 API를 수정할 필요가 없다.
- 필드에 접근할 때 부가적인 로직을 추가할 수 있다.

6. 리팩터링된 코드 및 설명

위의 Time 클래스는 불변성을 보장하지만, 여전히 필드를 직접 노출하고 있습니다. 필드 접근을 제한하면서도 내부 상태를 안전하게 유지할 수 있는 더 나은 방식

리팩터링된 Time 클래스:

public final class Time {
    private static final int HOURS_PER_DAY = 24;
    private static final int MINUTES_PER_HOUR = 60;
    
    private final int hour;
    private final int minute;

    public Time(int hour, int minute) {
        if (hour < 0 || hour >= HOURS_PER_DAY)
            throw new IllegalArgumentException("시간: " + hour);
        if (minute < 0 || minute >= MINUTES_PER_HOUR)
            throw new IllegalArgumentException("분: " + minute);
        this.hour = hour;
        this.minute = minute;
    }

    public int getHour() {
        return hour;
    }

    public int getMinute() {
        return minute;
    }

    // 추가적인 로직 필요 시 이곳에 부가 메서드를 추가할 수 있음
}

리팩터링 설명:

필드를 private으로 변경: hour와 minute 필드를 private으로 감추고, getter 메서드를 통해 값을 제공하도록 수정했습니다. 이렇게 하면 직접 필드에 접근할 수 없게 되어 내부 상태가 보호된다.
불변성을 유지: 클래스의 불변성은 유지되며, 필드에 직접 접근할 수 없는 대신 메서드를 통해 값에 접근할 수 있다.
캡슐화와 유연성: 이러한 방식은 이후 내부 표현을 변경해야 할 때, 외부 API를 수정할 필요 없이 내부 로직만 수정하면 되도록 유연성을 제공한다.

이제 클라이언트 코드가 Time 객체의 필드를 직접 수정하지 못하며, 객체 내부 상태를 안전하게 보호할 수 있다. 불변식도 유지되며, 필드 접근 시 필요에 따라 부수 작업을 추가할 수 있는 구조를 갖추게 된다.

7. 부가적인 예제

가변 필드와 불변 필드란 무엇인가요?

가변 필드(Mutable Field)

가변 필드는 값을 변경할 수 있는 필드를 말한다.
보통 필드에 대한 setter 메서드를 제공하거나, 필드가 public으로 선언되어 외부에서 직접 값을 변경할 수 있을 때 가변 필드가 된다.
예를 들어, int age; 필드가 있고, 외부에서 person.age = 30;으로 값을 변경할 수 있다면, age는 가변 필드이다.

불변 필드(Immutable Field)

불변 필드는 값을 변경할 수 없는 필드를 말합니다.
필드를 private final로 선언하고, setter 메서드를 제공하지 않으면 불변 필드가 됩니다.
초기화 이후에 값이 변경되지 않으므로 객체의 상태가 안정적입니다.
예를 들어, private final String id; 필드는 불변 필드입니다.

필드 노출의 문제점 예시

public class BankAccount {
    public double balance; // 계좌 잔액을 public으로 노출

    public BankAccount(double initialBalance) {
        this.balance = initialBalance;
    }
}

외부에서 account.balance = -1000;처럼 계좌 잔액을 음수로 설정할 수 있다.
이는 논리적으로 말이 안 되며, 은행 시스템의 무결성을 해친다.

개선된 BankAccount 클래스

public class BankAccount {
    private double balance; // 필드를 private으로 숨김

    public BankAccount(double initialBalance) {
        if (initialBalance < 0)
            throw new IllegalArgumentException("초기 잔액은 음수일 수 없습니다.");
        this.balance = initialBalance;
    }

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {
        if (amount <= 0)
            throw new IllegalArgumentException("입금 금액은 양수여야 합니다.");
        balance += amount;
    }

    public void withdraw(double amount) {
        if (amount <= 0)
            throw new IllegalArgumentException("출금 금액은 양수여야 합니다.");
        if (balance < amount)
            throw new IllegalArgumentException("잔액이 부족합니다.");
        balance -= amount;
    }
}

메서드를 통해서만 잔액을 변경할 수 있다.
유효성 검사를 통해 잘못된 금액이 입력되지 않도록 한다.

✨ 정리

public 클래스는 가변 필드를 직접 노출하지 말아야 하며, 불변 필드라 하더라도 API 유연성을 위해 노출을 피하는 것이 좋다.
패키지-프라이빗 클래스나 private 중첩 클래스에서는 때때로 필드를 직접 노출하는 것이 더 간결하고 유리할 수 있다.
캡슐화를 통해 클래스 내부의 필드를 보호하고, 필드의 값을 관리하기 위해 접근자(getter)와 변경자(setter) 메서드를 사용하는 것이 좋다.

Previousitem 15 : 클래스와 멤버의 접근 권한을 최소화하라 Nextitem 17 : 변경 가능성을 최소화하라

Last updated 1 month ago