진정한 의미의 캡슐화

[leeys9423]

💡 이슈

진정한 의미의 캡슐화란?

❓ 이유

이번 챕터는 객체 지향의 4대 특성을 다룹니다.

제가 생각하기에 상속, 추상화, 다형성은 문법적으로도 명확하기도 하고 객체지향하면 가장 먼저 떠오르는 키워드 일 것 같습니다.

그래서 저는 반대로 4대 특성 중에 그나마 덜 언급되는 캡슐화에 대해서 다뤄보고자 합니다.

우리가 흔히 착각하는 캡슐화는 단지 인스턴스 변수들을 private을 사용하여 접근 범위를 줄여 getter와 setter 메서드를 사용하여 인스턴스 변수에 접근할 수 있도록 도와준다 정도로 쉽게 생각하고 있을거에요.

하지만 이거는 진정한 의미의 캡슐화가 아니라고 생각합니다.(만약 맞다면 책에서 이렇게 언급되지도 않았을 거 같아요!)

서론이 길었는데, 진정한 의미의 캡슐화는 뭘까요? 혹은 타 커뮤니티에서는 getter와 setter가 캡슐화를 오히려 헤친다는 의견도 있었습니다. 이런 의견에 대한 각자의 생각을 들어보고 싶어요

📖 관련 페이지

[Cupcakes33]

캡슐화의 원칙은 단순하 '데이터를 숨기는 것' 에 있다고 생각하지 않아요.
숨기는 것에 집중하다보면 조금 본질을 놓칠 수 있다고 생각하거든요.
제가 생각하는 본질은 '변경으로 인한 사이드 이펙트를 제어하는 설계를 지향하자' 입니다.
풀어서 설명하자면, 캡슐화가 잘됐다! 의 기준은 상태를 직접 다루지 않고 의미 있는 행동을 통해 간접적으로 변경하고 있는가? 를 생각해봐야 한다는거에요.

이슈로 제기하신 setter나 getter 도 결국 메서드이고 상태를 변경하는 기능을 수행합니다.
하지만 객체지향에서 말하는 '행동'은 단순히 상태를 변경하는 동작이 아니라 '도메인 상에서 의미 있는 변화' 를 나타내야 합니다.
예를들면, '나이를 1 증가시킨다' 와 '이 사람은 생일이 지났으니까 나이를 올린다' 는
코드로 표현하면 비슷할 수도 있지만, 문법적으로 의미는 전혀 다르죠 ?
후자는 도메인 상에서 설정한 객체의 맥락, 규칙이나 정책을 반영하기 때문이에요.
이때, 올바른 객체지향 설계를 지향한다면 사람의 나이를 계산하는 정책이 바뀌더라도, 그 변경을 외부에서는 알지 못해야 합니다.

만약, setAge() 같은 단순한 setter 메서드를 사용한다면, 외부에서 객체의 내부 정책과 상관없이 나이를 마음대로 설정할 수 있어요.
반대로 applyUserAgePolicy() 처럼 정책을 적용하는 메서드를 만들어 age 의 상태를 제어한다면,
객체의 내부 불변을 보장하면서도 확장이 가능하도록 설계할 수 있습니다.

결국, 생각해보면 캡슐화 라는 표현이 '데이터 은닉' 에 조금 더 관점이 집중되어 있지만,
조금 풀어서 '변경 이유의 경계 설정과 사이드 이팩트 제어' 로 봐야하지 않을까? 합니다.

[yslee-dev]

정성스러운 답변 너무너무 감사하고 잘 읽었습니다!!!

써주신 내용 중

객체의 내부 불변을 보장하면서도 확장이 가능하도록 설계할 수 있습니다.

위와 같은 문장이 있는데, 불변식을 말씀해주시는 거겠죠?

[Cupcakes33]

불변식이라는게 어떤걸 말씀하시는걸까요?

[leeys9423]

불변식이란, 객체가 정상적으로 작동하기 위해 생명주기 동안 절대 깨져서는 안 되는 규칙이나 조건을 말해요.

예를 들면,

• "나이는 항상 0 이상이어야 한다"
• "주문의 총액은 항상 주문 항목들의 합과 일치해야 한다"
• "직사각형의 너비와 높이는 항상 양수여야 한다"

// 불변식: age는 항상 0 이상이어야 함
public void applyUserAgePolicy() {
    this.age = calculateAge();
    assert age >= 0;  // 불변식 검증
}

불변을 언급해주셔서, 불변 객체(Immutable Object)를 말씀해 주시는 건지 불변식(Invariant)을 말씀해 주시는 건지 헷갈려서 여쭤봅니다!

[Shim-sim]

주호님의 의견에 공감되는 부분이 많았습니다!
특히 "캡슐화를 단순한 데이터 은닉이 아니라, 변경의 영향 범위를 줄이는 구조로 본다"라는 관점이 좋았습니다.

저는 여기에 한 가지를 더 붙여보고 싶은데, setter가 자유롭게 열려있는 객체는 "이 값이 왜 이렇게 바뀌는지"에 대한 맥락이 코드 밖으로 밀려나는 경우가 종종 생기는 것 같습니다.
예를들면 혼자 개발할때는 setAge(99)가 "아 생일이 지나서 올렸구나"를 직관적으로 이해할 수 있는데,
동료 입장에서는 "왜 지금 이 시점에 age가 바뀌는지" 그게 비즈니스적으로 "생일"인지 혹은 "정책 변경"인지 코드만 봐서는 파악하기 어려울 수 있다고 느꼈어요.
반면에 주호님이 말씀주신대로, applyAgePolicy()와 같은 의도 기반 메서드가 있다면, 코드를 읽는 사람 입장에서도 객체의 변화에 대해서 자연스럽게 따라갈 수 있고, 정책이 바뀌어도 그 변화가 객체 내부에만 머무르기 때문에 외부 코드의 영향을 받지 않고 안정적으로 유지할 수 있다고 생각합니다!

다만 여기서 한 가지 더 궁금한 점이 생기는데요.
도메인 상 의미 있는 메서드를 계속 객체 내부에 두다 보면, 해당 객체가 너무 많은 책임을 갖게 되면서 무거워지는 상황도 발생할 수 있을 것 같습니다.
이럴 때 객체가 담당해야 하는 책임의 범위를 어디까지로 보시는지 의견 듣고싶어요!

(물론 이 부분은 도메인 구조에 따라서 달라질 수 있다고 생각해요.. 하나의 도메인이 비교적 독립적인 경우 그안에서 변경을 하는것이 자연스러울 수 있지만, 여러 도메인과 강한결합으로 이루어질 경우 외부 변화가 어느 정도는 필연적으로 전달될 수 밖에 없기도하니까요..)
결론은 "어디까지 객체의 책임으로 볼 것인가"의 기준이 궁금합니다.

[yslee-dev]

말씀하신 것처럼, 의미 있는 메서드를 계속 추가하다 보면 객체가 비대해지는 문제가 생길 수 있어요.

이럴 때 대표적으로 사용하는 방법 중 하나는 값 객체(Value Object)로 책임을 분리하는 거예요.

예를 들면

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Post {

    ...

    @Embedded
    private PostTitle title;

    @Embedded
    private PostContent content;

    ...
}

@Embeddable
public record PostTitle(String title) {

    public PostTitle {
        if (title.isEmpty() || title.length() > 100) {
            throw new IllegalArgumentException("게시글 제목은 1자 이상 100자 이하여야 합니다: " + title);
        }

        if (isBlank(title)) {
            throw new IllegalArgumentException("제목은 공백으로만 구성될 수 없습니다");
        }
    }
}

이렇게 하면 Post는 "게시글 생명주기"에만 집중하고, 제목/내용의 검증은 각 값 객체가 담당하게 돼요. 말씀해주신 비대해지는 문제를 해결할 수 있다고 봅니다!

[Cupcakes33]

도메인 상 의미 있는 메서드를 계속 객체 내부에 두다 보면, 해당 객체가 너무 많은 책임을 갖게 되면서 무거워지는 상황도 발생할 수 있을 것 같습니다.
이럴 때 객체가 담당해야 하는 책임의 범위를 어디까지로 보시는지 의견 듣고싶어요!

객체가 '너무 많은 책임을 가지고 있지 않은가?' 의 판단 기준은 SRP, '변경의 이유가 몇 가지인가?' 를 생각해보면 좋을 것 같슴니다.
예를들어, 위에서 든 예시의 User 객체가 생일을 축하한다! 는 책임, 나이를 계산하는 정책에 대한 책임, 생일이니까 포인트를 줄게요! 같은
여러 정책에 대한 책임을 모두 가지고 있다면, 정책이 변경되었을 때 3가지의 서로 다른 변경 사유가 되므로 이는 분리하는 편이 좋습니다.
반대로, 나이를 계산하는 모든 규칙이 한 곳에서, User 에 종속되어 유지되어야 한다면
이건 하나의 책임으로 볼 수 있으므로 User 내부에 있어도 괜찮습니다.
예시가 잘 와닿으실지는 잘 모르겠네요.

조금 단순하게 분리해서 한번 생각해볼까요?
캡슐화는 '외부에 노출되는 변경의 영향 범위를 최소화' 에 초점을 맞추고
책임의 분리는 '객체가 가진 변경 사유가 하나인가' 에 초점을 맞추면 좋을 것 같슴니다.

[Cupcakes33]

불변을 언급해주셔서, 불변 객체(Immutable Object)를 말씀해 주시는 건지 불변식(Invariant)을 말씀해 주시는 건지 헷갈려서 여쭤봅니다!

위에서 언급한 불변은 객체가 특정 정책을 적용하더라도 내부 규칙이 깨지지 않도록 한다는 것을 의미해요.
값이 변하더라도 항상 논리적으로 일관된 상태를 유지한다를 보장하자. 인거죠?
불변식이 맞는 것 같슴니다!