[JAVA] 접근제한자 & 캡슐화

🔒

Java Concept: Access Modifier & Encapsulation

접근제한자와 캡슐화, 그리고 더 나은 설계를 위한 메서드 활용법을 다룹니다.

자바 프로그래밍을 하다 보면 public, private 같은 단어들을 매일 마주하게 됩니다. 처음에는 "그냥 다 public으로 하면 편하지 않나?"라고 생각할 수 있습니다.

 

하지만 이 접근제한자(Access Modifier)야말로 객체 지향의 핵심인 보안과 무결성을 지키는 문지기 역할을 합니다.

 

오늘은 접근제한자의 종류와 범위부터, Getter/Setter의 장단점, 그리고 최근 실무에서 Getter/Setter 대신 선호하는 "의미 있는 메서드 설계"까지 완벽하게 정리해 보겠습니다.

 

---

 

1. 접근제한자 완벽 정리 (Scope)

접근 제한자는 "누구까지 들어오게 해줄 것인가?"를 결정하는 문지기입니다. 자바에는 4가지 등급의 보안 레벨이 있습니다.

접근제한자	내 클래스	같은 패키지	상속받은 자식	외부 전체
public	⭕	⭕	⭕	⭕
protected	⭕	⭕	⭕	❌
default (생략)	⭕	⭕	❌	❌
private	⭕	❌	❌	❌

Tip: 실무에서는 대부분 private(변수)과 public(메서드)을 주로 사용하며, 상속 관계 설계를 위해 protected를 종종 사용합니다.

 

---

2. 캡슐화와 Getter/Setter의 기본

캡슐화(Encapsulation)란?

객체의 중요한 데이터(필드)를 외부에서 마음대로 건드리지 못하게 꽁꽁 숨기는(private) 것입니다.

대신 안전하게 접근할 수 있는 통로(public 메서드)만 열어둡니다.

기본 사용법 (Java Beans 패턴)

public class Organism {
    // 1. 데이터는 private으로 숨김 (정보 은닉)
    private String name;
    private int age;

    // 2. Getter: 읽기 전용 통로
    public String getName() {
        return name;
    }

    // 3. Setter: 쓰기 전용 통로 (검증 로직 포함 가능)
    public void setAge(int age) {
        if (age < 0) {
            System.out.println("나이는 음수가 될 수 없습니다.");
            return;
        }
        this.age = age;
    }
}

 

---

3. Getter/Setter의 장단점 분석

"그냥 변수를 public으로 풀면 편한데 왜 귀찮게 Getter/Setter를 쓸까요?"

 

✅ 장점 (Pros)

• 무결성 보장: setAge(-5)처럼 말이 안 되는 데이터 입력을 if문으로 막을 수 있습니다.
• 접근 제어: Getter만 만들면 읽기 전용(Read-only) 필드로 만들 수 있습니다.
• 유지보수: 내부 변수명이 바뀌어도, 메서드 이름은 그대로 유지하여 외부 코드 수정을 막을 수 있습니다.

❌ 단점 (Cons)

• 캡슐화 위반 위험: 무분별한 Setter 남발은 사실상 public 변수와 다를 바 없습니다.
• 객체 수동성: 객체가 스스로 일을 처리하지 않고, 외부에서 값을 꺼내서(Get) 처리하고 다시 넣는(Set) 절차 지향적인 코드가 되기 쉽습니다.

---

4. 실무 트렌드: 의미 있는 메서드 설계

최근에는 "단순한 Setter 대신, 행위를 나타내는 메서드를 만들어라"라는 원칙이 강조되고 있습니다.

BAD - 단순 Setter 사용

Order order = new Order();
order.setStatus("SHIPPED"); // "상태를 바꾼다"는 단순한 데이터 변경

이 방식은 '왜' 상태가 바뀌는지, 배송이 시작되면 '무엇'을 더 해야 하는지(예: 알림 발송) 알기 어렵습니다.

GOOD - 비즈니스 용어 사용

public class Order {
    private String status;

    // 의미 있는 이름을 가진 메서드 (Setter 대체)
    public void startShipping() {
        if (this.status.equals("PAYMENT_COMPLETED")) {
            this.status = "SHIPPED";
            sendNotification(); // 관련된 로직도 함께 처리 가능!
        }
    }
}

// 사용처
order.startShipping(); // "배송을 시작해라!" (의도가 명확함)

 

이렇게 하면 코드만 읽어도 "아, 지금 배송 처리를 하는구나"라고 명확하게 의도를 파악할 수 있습니다.

 

 

---

5. 요약 및 결론

• 접근제한자: private(나만) < default < protected < public(모두)
• 캡슐화: 데이터는 private으로 숨기고, 필요한 경우에만 메서드로 열어주자.
• Getter/Setter: 데이터 무결성을 위해 필요하지만, 무분별한 사용은 지양하자.
• Tip: 단순히 값을 넣는 setXxx()보다는 cancelOrder(), updateUserInfo() 처럼 의도가 드러나는 이름을 짓자!

 

💡 마무리:
좋은 객체는 자신의 데이터를 남에게 그냥 보여주지 않고(Getter), 외부에서 시키는 대로 그냥 값을 바꾸지 않습니다(Setter).
"스스로 데이터를 관리하고 행동하는 객체"를 만드는 것이 OOP의 핵심입니다.