답변.

질문 역사:

캡슐화는 C++가 등장하면서부터 존재하는 OOP의 핵심 원칙 중 하나입니다. 아이디어는 객체의 내부 상태에 대한 접근을 제한하고, 이를 다루기 위한 신중하게 설계된 인터페이스만을 제공하는 것입니다. C++에서 캡슐화는 클래스 멤버의 접근 범위를 통해 형식화됩니다: public, protected, private.

문제:

캡슐화를 사용하지 않으면 객체의 내부 상태가 프로그램의 어느 곳에서나 수정될 수 있어, 오류와 디버깅하기 어려운 버그, 그리고 전반적인 신뢰성 저하로 이어질 수 있습니다. 지나치게 폐쇄적일 경우에는 클래스의 유지보수와 사용이 어렵게 됩니다.

해결책:

클래스의 인터페이스 (public 섹션)와 구현 (private/protected)을 명확히 구분해야 합니다. 중요한 데이터에 접근하기 위해 특수한 메서드 (getter/setter)를 사용하고, 복잡한 로직은 추가 클래스나 템플릿을 통해 분리해야 합니다. const 메서드를 사용하여 상태의 불변성을 보장합니다.

코드 예시:

class Counter {
private:
    int value;
public:
    Counter() : value(0) {}
    void increment() { ++value; }
    int get() const { return value; }
};

주요 특징:

세 가지 접근 범위: public, protected, private.
객체와 상호작용하기 위한 필요한 메서드만을 구현할 수 있습니다.
내부 데이터와 메서드에 대한 접근 제한.

속임수가 있는 질문들.

다른 객체의 private 멤버에 직접 접근할 수 있나요, 같은 클래스 안에서 메서드 내에서?

네, 클래스의 메서드 내에서는 같은 클래스의 다른 객체의 private 멤버에 접근할 수 있습니다.

class Example {
    int val;
public:
    void copyVal(const Example& other) { val = other.val; } // 오류 없음!
};

친구 함수가 클래스의 private 멤버에 접근할 수 있나요?

네, friend 함수는 클래스의 private/protected 멤버에 완전한 접근 권한을 가집니다.

생성자를 private으로 만들 수 있나요? 필요한 이유는 무엇인가요?

네, private 생성자는 종종 싱글톤과 팩토리 메서드에서 클래스 인스턴스 생성을 제어하기 위해 사용됩니다.

일반적인 오류와 안티 패턴

모든 클래스 멤버가 public으로 선언됨
Getter/Setter가 실제 제약 없이 형식적인 래퍼로 전락
SRP 위반: Open-Access Class

실생활 예시

부정적인 사례

BankAccount 클래스가 public 변수 balance를 포함합니다. 어떤 외부 코드라도 직접적으로 잔액을 변경할 수 있으며, 이는 조사하기 거의 불가능한 오류로 이어집니다.

장점:

사용하기 간편함

단점:

변경에 대한 통제가 없고, 제한이나 감사 추가가 불가능함

긍정적인 사례

변수 balance는 숨겨져 있으며, 잔액을 변경하기 위한 보호된 메서드만 존재합니다. 검증은 클래스 내부에서 이루어집니다.