これは友人関係の適切な使用ですか？

Question

ウィンドウの親と子のダイアログクラスを作成するときは、一般的に、子クラスを親クラスのフレンドにしてプライベートデータにアクセスさせるか、アクセサー関数を使用するのが良いでしょうか？

Answer 1

IMHO、ほとんど決してありません。

「友人」は、外部エンティティがクラスのプライベートデータにアクセスすることを許可するという点で、カプセル化を中断する傾向があることがよくあります。あなたはほとんどこれをやりたいとは決してありません。プライベートな情報を別のクラス（あなたのいたるところで知り合うことができる）に公開するよりも、公共のアクセサ（妥当性をチェックできる）を介して "セミプライベート"データを公開する方がより安全です。

しかし、非常に密接に関連したクラスのペア/グループを持つことがありますが、クラスを別々のクラスにしておくのが理にかなっていますが、世界全体と共有するべきではないデータ。これは「友人」が注意を払って使用できる場所です。

一般に、プライベートデータへの直接アクセスが許可される領域を最小限に抑えるため、フレンドの範囲（フレンドクラスではなくフレンドメソッドなど）を制限してください。できるだけシンプルにしてください。あなたのコードを読んでいる別のプログラマーが、「プライベート」とは、データが本当にプライベートであることを意味するかもしれないと覚えておいてください。また、使用する友人が多いほど、より密接に結びつき、設計を維持するのが難しい傾向にあります。これらは便利なこともありますが、それぞれの用途に適切な正当性があることを確認してください。

Answer 2

友人の必要性はまれです - 一般的に、1つのクラスでいくつかの深い振る舞いを再実装する必要はありません。どちらも、単一のベースから継承したり、多くのアクセサを提供したりせずに書き換えません。

OpenGLベースのレンダラをActiveXで書き直す必要があったのは、低レベルのモデルデータをたくさん用意する必要があったが、（技術的理由以外の理由で）共通のABCを再実装できなかった。

Answer 3

私はクラスB

にクラスAのいくつかのプライベートメンバ変数を公開したかったところ、私はこれがすべてにこれらのメンバーを公開しますので、私は公共のアクセサ関数を追加したくなかった、最近似たような状況がありました他のクラス。

これはB.

へのすべてのプライベートメンバーを公開しますので、私は単にその目的のために別のクラス（ツーBプライベートインターフェイス）を作ったので、私はAの友人b作りたくありませんでした。それはAの友人であり、それは、アクセサ関数を除いては何もしています：

class A 
{ 
    int top_secret; // only A has access to it 
    int secret; // only A and B have access to it 
    friend struct AToBInterface; 
}; 

struct AToBInterface 
{ 
    static int secret(const A& object) {return object.secret;} 
}; 

class B 
{ 
    void DoSecretStuff(A& object) 
    { 
     int secret = AToBInterface::secret(object); 
     ... 
    } 
}; 

あなたは構文を微調整することができます（あなたは読み書きアクセスを必要とするなどあれば）、それだけで考えです。私はコード内で1つの場所にしか使用しないので、構文が少し毛深いならば問題はありません。