回答。

問題の歴史:

カプセル化は、C++の登場以来のOOプログラミングの主要な原則の1つです。アイデアは、オブジェクトの内部状態へのアクセスを制限し、考慮されたインターフェースのみを提供してそれに対処できるようにすることです。C++では、カプセル化はクラスのメンバーの可視性の範囲を介して形式的に整備されています：public、protected、private。

問題:

カプセル化を使用しないと、オブジェクトの内部状態はプログラムのどの場所からも変更できるため、エラーやデバッグが難しいバグ、全体的な信頼性の低下を引き起こします。一方、過剰なカプセル化は、クラスのメンテナンスや使用を難しくすることがあります。

解決策:

クラスのインターフェース（publicセクション）と実装（private/protected）を明確に区別します。重要なデータへのアクセスには特別なメソッド（ゲッター/セッター）を使用します。複雑なロジックでは、追加のクラスやテンプレートを介してメカニズムを分割します。状態の変更を防ぐためにconstメソッドを使用します。

コード例:

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

主な特徴:

3つの可視性の範囲: public, protected, private。
オブジェクトとの対話に必要なメソッドのみを実装可能。
内部データおよびメソッドへのアクセスを制限。

トリビア問題。

クラスのメソッド内で、同じクラスの他のオブジェクトのprivateメンバーに直接アクセスできますか？

はい、クラスのメソッド内では、同じクラスの他のオブジェクトのprivateメンバーにアクセスできます。

class Example {
    int val;
public:
    void copyVal(const Example& other) { val = other.val; } // エラーなし！
};

友達関数はクラスのprivateメンバーにアクセスできますか？

はい、friend関数はクラスのprivate/protectedメンバーに完全にアクセスできます。

コンストラクタをprivateにすることは可能ですか？それはなぜ必要ですか？

はい、プライベートコンストラクタは、シングルトンやファクトリメソッドでクラスのインスタンス生成を制御するためによく使用されます。

一般的なエラーとアンチパターン

すべてのクラスメンバーがpublicとして宣言されている
ゲッター/セッターが実際の制限なしの形式的なラッパーになる
SRPの違反: オープンアクセスクラス

現実の例

ネガティブケース

BankAccountクラスは、public変数balanceを含んでいます。外部のコードが直接バランスを変更できるため、調査がほぼ不可能なエラーが発生します。

メリット:

使用が簡単

デメリット:

変更に対する制御がなく、制限や監査を追加することができない

ポジティブケース

バランス変数は隠されており、バランスを変更するための保護されたメソッドのみがあります。検証はクラス内で実装されています。