A-3: 좋은 객체 — 묻지 말고 시켜라, 속을 감춰라

안녕하세요, 여러분의 코드 안목을 길러 드릴 홍순구 튜터입니다.

지난 시간엔 함수를 다뤘죠. 작게 쪼개고, 한 가지 일만 하게 하고, 인자를 줄이고, 숨은 동작을 걷어냈습니다. 그 Step 2에서 주문 합계를 구하는 total() 함수를 만들었던 것 기억하시나요? 그때 제가 슬쩍 이런 그림을 던졌습니다. 만약 Order가 가진 항목 목록을 바깥으로 다 꺼내 주고, 합계 계산은 엉뚱한 다른 곳에서 했다면 어땠을까요? 오늘은 바로 그 이야기입니다. 함수가 사는 집, 객체를 다듬는 시간이에요.

신입이 코드 리뷰에서 객체를 두고 자주 듣는 세 마디가 있습니다.

• "이 객체, getter로 속을 다 까발리네요."
• "여기 점(.)이 세 번이나 찍혀 있어요."
• "이 객체, 값이 아무 데서나 바뀌는데요?"

세 마디 모두 객체를 잘 만들었는가에 대한 지적입니다. 좋은 이름과 작은 함수를 갖췄으니, 이제 그것들을 품는 객체 자체를 다듬을 차례예요. 객체에게 일을 시키고, 속을 감추고, 함부로 바뀌지 않게 지키는 법. 그리고 이 과목이 계속 강조하는 한 가지, 각 규칙을 언제 깨야 하는지까지 함께 봅니다.

   A-2 함수 설계
   "함수 한 개를 작게, 한 가지만"
        │
        ▼
   A-3 좋은 객체·캡슐화          ◀ 오늘 여기
   "객체에게 시키고, 속을 감추기"
        │
        ▼
   A-4 에러 처리·경계
   "실패와 없음을 안전하게"

오늘 다룰 다섯 걸음을 두 갈래로 묶어 봤습니다.

 [객체란 무엇인가]
   ① 객체 vs 자료구조  →  ② 묻지 말고 시켜라  →  ③ 기차 충돌(디미터)

 [속을 지키기]
   ④ 캡슐화  →  ⑤ 불변성

💡 오늘 수업의 핵심 — "객체에게 묻지 말고 시켜라 — 속은 감추고, 행동으로 연다"

🎯 학습 목표

• 객체와 자료구조의 차이를 알고, 언제 캡슐화하고 언제 그냥 데이터로 둘지 판단한다.
• 묻지 말고 시켜라(Tell, Don't Ask)와 디미터 법칙으로 객체가 속을 까발리지 않게 한다.
• 캡슐화와 불변성으로 객체의 상태를 안전하게 지키고, 각 규칙을 언제 깰지도 함께 익힌다.

Step 1: "두 종류의 코드 — 객체와 자료구조"

객체지향을 배우면 이런 주문을 외웁니다. "모든 걸 객체로 만들어라. 필드는 다 private로 숨기고, getter와 setter를 달아라." 그런데 사실 코드에는 성격이 다른 두 종류가 있습니다. 이 둘을 구분하지 못하면, 객체도 자료구조도 아닌 어정쩡한 잡종(hybrid)을 만들게 돼요.

• 자료구조(data structure): 데이터를 그대로 드러내고, 행동은 거의 없습니다. 좌표, 주소, 화면에 뿌릴 응답 같은 것이죠. 자바의 record가 대표적입니다.
• 객체(object): 데이터를 숨기고, 행동(메서드)을 드러냅니다. 계좌, 주문처럼 "스스로 일을 하는" 것이죠.

도형 넓이를 구하는 코드로 그 차이를 봅시다. 먼저 자료구조로 푸는 방식입니다. 도형은 데이터만 들고, 계산은 바깥의 AreaCalculator가 타입을 따져 가며 합니다.

❌ Before (자료구조 + 절차적 계산)

public record RectangleData(double width, double height) {
}

public record CircleData(double radius) {
}

public class AreaCalculator {

    public double calculate(Object shape) {
        if (shape instanceof RectangleData r) {
            return r.width() * r.height();
        }
        if (shape instanceof CircleData c) {
            return Math.PI * c.radius() * c.radius();
        }
        throw new IllegalArgumentException("알 수 없는 도형: " + shape.getClass());
    }
}

이번엔 객체로 푸는 방식입니다. 각 도형이 자기 넓이를 스스로 계산하게 하고, 데이터(width, radius)는 숨깁니다.

✅ After (객체)

public interface Shape {
    double area();
}

public class Rectangle implements Shape {

    private final double width;
    private final double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double area() {
        return width * height;
    }
}

Circle도 똑같이 Shape를 구현하고, area()에서 Math.PI * radius * radius를 돌려줍니다.

여기서 재미있는 비대칭이 보입니다. 두 방식은 "무엇을 추가하기 쉬운가"가 정반대예요.

 무엇을 자주 추가하나?
   타입(새 도형, 삼각형)을 자주 추가  →  객체 방식이 유리 (클래스 하나만 더 만들면 끝)
   연산(새 계산, 둘레)을 자주 추가     →  자료구조+절차 방식이 유리 (메서드 하나만 추가)

객체 방식에서 삼각형을 추가하려면 Shape를 구현하는 클래스 하나만 만들면 됩니다. 기존 코드는 손대지 않아요. 반대로 "둘레 계산"이라는 새 연산을 넣으려면 Shape 인터페이스를 바꾸고 모든 구현체를 고쳐야 합니다. 자료구조 방식은 정확히 그 반대고요.

그래서 정답은 "무조건 객체"가 아닙니다. 자주 바뀌는 축이 타입이냐 연산이냐를 보고 고르는 거예요.

⚠️ 언제 깨나 — 자료구조는 그냥 데이터로 두는 게 맞을 때가 많습니다. 화면에 뿌릴 응답이나 좌표처럼 데이터를 나르는 게 목적이라면 record가 정직한 표현이에요. 가장 나쁜 건 둘을 섞은 잡종입니다. 데이터를 getter로 다 드러내면서 어설픈 행동까지 끼워 넣으면, 자료구조의 안정성도 객체의 캡슐화도 둘 다 잃습니다.

💡 한 줄 정리

코드에는 데이터를 드러내는 자료구조와 데이터를 숨기는 객체, 두 종류가 있고, 자주 바뀌는 축을 보고 고른다. 둘을 섞은 잡종이 가장 위험하다.

Step 2: "묻지 말고 시켜라 (Tell, Don't Ask)"

지난 시간 약속한 그 이야기입니다. 함수 편 Step 2에서 주문 합계를 total()로 만들었죠. 오늘은 그 합계가 어디서 계산되어야 하는가를 따져 봅니다.

흔한 실수는 이렇습니다. 주문 객체에게 "네 항목 목록 좀 줘 봐"라고 묻고(Ask), 받아 온 목록을 바깥에서 돌며 직접 계산하는 거예요.

❌ Before (묻고 꺼내서 바깥에서 계산)

public class OrderBefore {

    private final List<LineItem> items;

    public OrderBefore(List<LineItem> items) {
        this.items = items;
    }

    public List<LineItem> getItems() {
        return items;
    }
}

public class CheckoutService {

    public int calculateTotal(OrderBefore order) {
        int total = 0;
        for (LineItem item : order.getItems()) {
            total += item.unitPrice() * item.quantity();
        }
        return total;
    }
}

LineItem은 이름·단가·수량을 담는 자료구조(record)입니다. 문제는 합계 계산이 Order 바깥, 그러니까 CheckoutService에 흩어져 있다는 점이에요. 만약 할인이 붙거나 항목 구조가 바뀌면, 이 계산을 베껴 쓴 모든 곳을 다 같이 고쳐야 합니다.

이번엔 시켜 봅시다(Tell). 합계는 Order가 가장 잘 아는 일이니, 그 일을 Order에게 맡깁니다.

✅ After (객체에게 시킨다)

public class OrderAfter {

    private final List<LineItem> items;

    public OrderAfter(List<LineItem> items) {
        this.items = items;
    }

    public int total() {
        int total = 0;
        for (LineItem item : items) {
            total += item.unitPrice() * item.quantity();
        }
        return total;
    }
}

호출부는 이제 order.total() 한 줄이면 끝입니다. 항목 목록을 꺼낼 일도, 계산식을 바깥에 둘 일도 없어요. 내부 구조가 바뀌어도 total()만 고치면 되고, 호출부는 영향을 받지 않습니다. 이게 "묻지 말고 시켜라"입니다. 객체에게 데이터를 달라고 묻지 말고, 그 데이터로 할 일을 시키세요.

⚠️ 언제 깨나 — 모든 걸 시키려 들면 객체가 온갖 책임을 떠안아 비대해집니다. 하나의 객체가 수십 가지 일을 다 하는 신(God) 객체가 되면 그것대로 문제예요. 그리고 조회 자체가 목적인 자료구조에서는 getter가 정당합니다. 화면에 이름을 뿌리려고 member.name()을 부르는 건 데이터를 묻는 게 아니라 그 객체의 떳떳한 쓰임이에요.

💡 한 줄 정리

객체에게 "데이터를 달라"고 묻지 말고 "이 일을 해 달라"고 시킨다. 결정과 계산은 데이터를 가진 객체 안에 둔다.

Step 3: "기차 충돌 — 디미터 법칙"

이번엔 점(.)을 세어 봅시다. 배송 라벨에 도시 이름을 찍으려고, 주문에서 고객을 꺼내고, 고객에서 주소를 꺼내고, 주소에서 도시를 꺼내는 코드입니다.

❌ Before (기차 충돌, train wreck)

// 점(.)이 세 번 — 주문 → 고객 → 주소 → 도시
String city = order.getCustomer().getAddress().city();

order.getCustomer().getAddress().city(). 점이 줄줄이 이어진 모습이 마치 기차가 충돌해 객차가 늘어선 것 같다고 해서 기차 충돌이라고 부릅니다. 이게 왜 나쁠까요? 이 한 줄을 쓰려면 호출부가 너무 많이 알아야 합니다. 주문이 고객을 들고 있고, 고객이 주소를 들고 있고, 주소에 도시가 있다는 내부 구조를 전부 꿰고 있어야 해요. 중간에 어느 하나라도 구조가 바뀌면 이 줄이 깨집니다.

이걸 막는 규칙이 디미터 법칙(Law of Demeter)입니다. "한 메서드는 자기 자신, 자기가 가진 필드, 인자로 받은 것, 자기가 만든 것에게만 말을 걸어라." 쉽게 말해 친구하고만 이야기하고, 친구의 친구에게는 말 걸지 마라예요. 그래서 객체를 타고 들어가지 말고, 각 객체가 자기 이웃에게만 묻도록 위임합니다.

✅ After (위임 — 점 하나씩)

public class OrderAfter {

    private final Customer customer;

    public OrderAfter(Customer customer) {
        this.customer = customer;
    }

    public String shipToCity() {
        return customer.cityForShipping();
    }
}

Customer는 자기 주소에게만 묻고, 호출부에는 도시만 돌려줍니다.

public class Customer {

    private final String name;
    private final Address address;

    // 생성자 · name() 생략

    public String cityForShipping() {
        return address.city();
    }
}

이제 호출부는 order.shipToCity() 한 줄입니다. 점이 하나죠. 주문은 고객에게만, 고객은 주소에게만 말을 겁니다. 중간 구조가 바뀌어도 호출부는 모르고, 알 필요도 없어요.

⚠️ 언제 깨나 — 자료구조(record) 체인은 디미터 예외입니다. Address는 데이터를 나르는 record라, address.city()로 값을 꺼내는 것 자체는 위반이 아니에요. 진짜 문제는 객체인 Customer가 자기 속의 주소를 통째로 내줘서, 호출부가 그 속을 타고 들어가게 만드는 부분입니다. 또 위임 메서드를 무조건 만들면 shipToCity, customerName, customerEmail처럼 껍데기 메서드만 수십 개로 불어날 수 있어요. 진짜 필요한 행동만 위임하세요.

💡 한 줄 정리

점을 줄줄이 잇는 기차 충돌은 호출부가 남의 속을 너무 많이 알게 만든다. 친구의 친구에게 말 걸지 말고, 각 객체가 자기 이웃에게만 묻도록 위임한다.

Step 4: "속을 감추고 의미로 연다 — 캡슐화"

이번 후크는 "객체가 getter로 속을 다 까발려요"입니다. 계좌를 봅시다. 잔액을 getBalance로 읽고 setBalance로 쓰게 열어 두면 어떤 일이 벌어질까요?

❌ Before (getter/setter로 잔액을 드러낸 계좌)

public class AccountBefore {

    private int balance;

    public AccountBefore(int initialBalance) {
        this.balance = initialBalance;
    }

    public int getBalance() {
        return balance;
    }

    public void setBalance(int balance) {
        this.balance = balance;
    }
}

출금은 이렇게 합니다.

// 바깥에서 잔액을 꺼내 직접 빼고 다시 넣는다
account.setBalance(account.getBalance() - amount);

balance는 분명 private인데, setBalance가 열려 있으니 사실상 누구나 잔액을 마음대로 덮어쓸 수 있습니다. "잔액보다 많이 출금할 수 없다" 같은 규칙을 어디서도 강제할 수 없어요. 출금할 때마다 그 규칙을 매번 기억해야 하고, 한 군데라도 빠뜨리면 잔액이 음수가 됩니다.

캡슐화(encapsulation)는 데이터를 숨기는 데서 끝나지 않습니다. 그 데이터를 바꾸는 규칙을 객체 안에 모으는 것이 핵심이에요. setter를 없애고, 입금과 출금이라는 의미 있는 행동으로만 잔액을 바꾸게 합니다.

✅ After (의미 메서드로만 바꾸는 계좌)

public class AccountAfter {

    private int balance;

    public AccountAfter(int initialBalance) {
        this.balance = initialBalance;
    }

    public void deposit(int amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("입금액은 0보다 커야 합니다.");
        }
        this.balance += amount;
    }

    public void withdraw(int amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("출금액은 0보다 커야 합니다.");
        }
        if (amount > balance) {
            throw new IllegalStateException("잔액이 부족합니다.");
        }
        this.balance -= amount;
    }

    public int balance() {
        return balance;
    }
}

이제 출금은 account.withdraw(amount) 한 줄이고, 잔액 부족 검사는 withdraw 안에 단 한 번만 있습니다. 바깥 어디서 출금하든 같은 규칙이 강제돼요. 잔액을 읽기만 하는 balance()는 남겨 둡니다. 화면에 잔액을 보여 줘야 하니까요. 이렇게 읽기는 열어 두되, 바꾸기는 의미 있는 행동으로만 여는 게 캡슐화입니다.

⚠️ 언제 깨나 — getter/setter를 기계적으로 전부 다는 건 캡슐화가 아니라 그 반대입니다. 도구로 @Getter @Setter를 한 번에 붙이는 습관은, 애써 숨긴 필드를 도로 다 열어 버려요. 캡슐화의 핵심은 "필드를 private로 했는가"가 아니라 "그 필드를 바꾸는 규칙을 안에 모았는가"입니다. 반대로 데이터 운반이 목적인 자료구조라면 접근자는 정당하니, 거기에 억지로 행동을 욱여넣지 마세요.

💡 한 줄 정리

캡슐화는 데이터를 숨기는 것을 넘어, 그 데이터를 바꾸는 규칙을 객체 안에 모으는 것이다. setter를 의미 있는 행동 메서드로 바꾼다.

Step 5: "바뀌지 않아 안전한 객체 — 불변성"

마지막 후크는 "이 객체, 값이 아무 데서나 바뀌어요"입니다. 예약 손님 명단을 봅시다. 생성자에서 받은 리스트를 그대로 들고 있고, getGuests로 그 리스트를 그대로 내주면 어떤 사고가 날까요?

❌ Before (가변 + 내부 리스트 노출)

public class ReservationBefore {

    private String restaurantName;
    private List<String> guests;

    public ReservationBefore(String restaurantName, List<String> guests) {
        this.restaurantName = restaurantName;
        this.guests = guests;           // 참조를 그대로 저장 — 위험
    }

    // getRestaurantName · setRestaurantName 생략

    public List<String> getGuests() {
        return guests;
    }

    public void setGuests(List<String> guests) {
        this.guests = guests;
    }

    public int guestCount() {
        return guests.size();
    }
}

여기엔 함정이 숨어 있습니다. 생성자가 받은 리스트를 복사 없이 그대로 들고 있어요. 그래서 바깥 리스트를 건드리면 예약 명단도 같이 바뀝니다.

List<String> guests = new ArrayList<>(List.of("김재훈", "박지수"));
ReservationBefore r = new ReservationBefore("스시집", guests);

guests.add("불청객");        // 바깥 리스트에 한 명 추가했을 뿐인데
// r.guestCount() 가 3 으로 늘어난다 — 예약 내부 명단이 함께 바뀌었다

내가 만든 예약이 내가 모르는 사이에 바뀌는 거예요. 이런 공유 참조 사고는 추적하기가 정말 어렵습니다. 누가 언제 그 리스트를 건드렸는지 알 수가 없거든요.

불변성(immutability)은 이 문제를 뿌리째 없앱니다. 생성된 뒤로는 상태가 절대 바뀌지 않게 만드는 거예요. 필드를 final로 잠그고, setter를 없애고, 생성자에서 받은 리스트는 방어적 복사로 떠서 보관합니다.

✅ After (불변 + 방어적 복사)

public class ReservationAfter {

    private final String restaurantName;
    private final List<String> guests;

    public ReservationAfter(String restaurantName, List<String> guests) {
        this.restaurantName = restaurantName;
        this.guests = List.copyOf(guests);  // 방어적 복사 — 원본 변경 차단
    }

    public String restaurantName() {
        return restaurantName;
    }

    public List<String> guests() {
        return guests;
    }

    public int guestCount() {
        return guests.size();
    }
}

List.copyOf로 새 리스트를 떠 두니, 바깥에서 원본을 아무리 건드려도 예약 명단은 흔들리지 않습니다. 게다가 List.copyOf가 만든 리스트는 수정 불가라, guests().add(...)를 시도하면 예외가 납니다. 생성된 예약은 그 순간의 상태에서 더 바뀌지 않아요. 여러 곳에서 같은 객체를 공유해도 누가 몰래 바꿀까 걱정할 필요가 없습니다.

⚠️ 언제 깨나 — 모든 것을 불변으로 만드는 건 과합니다. 아주 큰 컬렉션을 바꿀 때마다 통째로 복사하면 비용이 커지고, 본래 상태가 자주 변하는 대상(게임 캐릭터의 위치, 담는 중인 장바구니)은 가변이 더 자연스러워요. 돈·좌표·기간처럼 작고 의미가 고정된 값부터 불변으로 만드는 게 좋은 출발점입니다.

그런데 여기서 한 가지 질문이 남습니다. 만약 예약을 찾았는데 손님 명단이 비어 있거나, 아예 예약을 못 찾으면 어떻게 돌려줘야 할까요? 빈 명단? null? 아니면 예외? 이 "없음"과 "실패"를 안전하게 다루는 이야기는 다음 시간 에러 처리에서 본격적으로 풀어 봅니다.

💡 한 줄 정리

불변 객체는 생성 후 상태가 바뀌지 않아 공유 참조 사고를 막는다. final 필드와 방어적 복사로 만들되, 작고 의미가 고정된 값부터 적용한다.

마무리

객체 하나를 잘 만드는 일, 생각보다 결이 깊죠? 오늘 우리는 "모든 걸 객체로, getter/setter 다 달아라"는 주문에서 벗어나, 객체가 스스로 일하고 자기 속을 지키게 만드는 법을 봤습니다.

오늘 배운 핵심 세 가지

💡 하나 — 두 종류의 코드. 데이터를 드러내는 자료구조와 데이터를 숨기는 객체는 서로 다른 도구다. 자주 바뀌는 축(타입이냐 연산이냐)을 보고 고르되, 둘을 섞은 잡종은 피한다.

💡 둘 — 묻지 말고 시켜라, 그리고 디미터. 객체에게 속을 묻고 꺼내 바깥에서 일하지 말고, 그 일을 객체에게 시킨다. 점을 줄줄이 잇는 기차 충돌 대신, 각 객체가 자기 이웃에게만 묻게 한다.

💡 셋 — 캡슐화와 불변성. 상태를 바꾸는 규칙을 객체 안에 모으고(캡슐화), 작고 의미가 고정된 값은 바뀌지 않게 지킨다(불변성). 단, 자료구조에는 억지로 적용하지 않는다.

다음 시간 예고

다음 시간엔 A-4 에러 처리·경계로 갑니다. 오늘 Step 5 끝에서 "명단을 못 찾으면 null을 줄까, 예외를 던질까?"를 잠깐 흘렸죠. 그 실패와 없음을 어떻게 다룰지를 정면으로 봅니다. 예외와 에러 코드 중 무엇을 쓸지, null을 반환하거나 넘기지 않는 법, 없음을 타입으로 표현하는 Optional, 그리고 외부 라이브러리가 바뀌어도 우리 코드가 안 터지게 감싸는 경계까지. "외부 API 바뀌니 우리 코드가 다 터졌어요"라는 단골 지적을, 그때 풀어 봅시다.

과제

오늘은 직접 Before를 After로 고치는 손 실습입니다. 코드베이스에 있는 예제와 다른 소재로 냈으니, 베끼지 말고 원리를 적용해 보세요.

[기초] 장바구니에게 합계를 시켜라 (Tell, Don't Ask)

아래 Cart는 항목 목록을 getItems()로 통째로 내주고, 합계 계산은 바깥 PriceService가 합니다. 이걸 "묻지 말고 시켜라"로 고치세요. Cart가 스스로 totalPrice()를 계산해 돌려주고, 호출부는 cart.totalPrice() 한 줄이 되게 만들면 됩니다.

public class Cart {
    private final List<CartItem> items;
    public Cart(List<CartItem> items) {
        this.items = items;
    }
    public List<CartItem> getItems() {
        return items;
    }
}

// 바깥에서 계산 중 — 이 흐름을 뒤집으세요
int total = 0;
for (CartItem item : cart.getItems()) {
    total += item.price() * item.count();
}

[응용] 재고를 캡슐화하라

아래 Inventory는 getStock/setStock으로 재고를 열어 둬서, 바깥에서 setStock(getStock() - n)으로 직접 깎습니다. 그래서 재고가 음수가 되는 사고를 아무도 못 막아요. setStock을 없애고, removeStock(int n)/addStock(int n) 같은 의미 메서드로만 바꾸게 하세요. 그리고 "재고는 0 밑으로 내려갈 수 없다"는 규칙을 removeStock 안에 모으세요.

public class Inventory {
    private int stock;
    public Inventory(int stock) {
        this.stock = stock;
    }
    public int getStock() {
        return stock;
    }
    public void setStock(int stock) {
        this.stock = stock;
    }
}

[심화] 팀 명단을 불변으로 (방어적 복사)

아래 Team은 받은 명단 리스트를 그대로 들고, getMembers()로 그대로 내줍니다. 그래서 바깥에서 원본 리스트나 반환된 리스트를 건드리면 팀 명단이 몰래 바뀝니다. 이 Team을 불변으로 바꾸세요. 필드를 final로 잠그고, setter를 없애고, 생성자에서 방어적 복사를 하고, 명단은 수정 불가능한 형태로 돌려주면 됩니다. 마지막으로, "생성자에 넘긴 원본 리스트를 나중에 바꿔도 팀 명단은 안 바뀐다"를 어떻게 확인할 수 있을지도 한 줄로 적어 보세요.

public class Team {
    private String teamName;
    private List<String> members;
    public Team(String teamName, List<String> members) {
        this.teamName = teamName;
        this.members = members;       // 그대로 저장 — 어디를 고쳐야 할까?
    }
    public List<String> getMembers() {
        return members;
    }
    public void setMembers(List<String> members) {
        this.members = members;
    }
}

생각해볼 주제

정답이 하나가 아닌 질문들입니다. 오늘 배운 원칙을 언제 적용하고 언제 깰지를 스스로 따져 보세요.

1. record(자료구조)와 캡슐화한 객체, 무엇을 언제 쓸까?

한쪽에서는 "객체지향이니 모든 걸 객체로 감싸고 데이터는 숨겨라"라고 하고, 다른 쪽에서는 "데이터를 나르는 건 그냥 record로 두라"고 합니다. 둘 다 맞는 말입니다. 그렇다면 새 클래스를 만들 때, 이게 자료구조여야 하는지 캡슐화한 객체여야 하는지를 무엇으로 가를 수 있을까요? 잡종을 피하려면 어떤 신호를 봐야 할지 각자의 기준을 세워 토론해 보세요.

2. getter는 정말 죄가 없을까?

"묻지 말고 시켜라"를 극단으로 밀면 이상한 결론에 도달합니다. 객체가 아무 값도 안 내주면, 화면에 이름 하나 뿌리는 것도 불가능해지죠. 그렇다고 모든 getter를 정당화하면 캡슐화가 무너집니다. 어디까지가 "정당한 조회"이고, 어디부터가 "속을 까발리는 노출"일까요? getItems() 다음에 무엇이 오느냐로 가른다는 오늘의 힌트를, 여러분의 코드에서 어떻게 적용할지 이야기해 보세요.

3. 불변이 항상 정답일까?

함수형 언어들은 불변을 기본값으로 둡니다. 바뀌지 않으니 안전하고, 동시성 문제도 줄죠. 그런데 자바에서 모든 객체를 불변으로 만들면, 큰 컬렉션을 바꿀 때마다 통째로 복사하는 비용이 듭니다. 본래 자주 변하는 대상은 가변이 더 자연스럽기도 하고요. 불변을 기본으로 삼되, 어떤 신호가 보일 때 가변을 허용하는 게 합리적일까요? 성능과 안전 사이의 균형점을 고민해 보세요.