プライベートフィールドがインスタンスではなく型に対してプライベートであるのはなぜですか？

C＃（および他の多くの言語）では、同じタイプの他のインスタンスのプライベートフィールドにアクセスすることは完全に正当です。例えば：

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if (anotherFoo.aBool) ...
    }
}

ようにC＃の仕様（セクション3.5.1、3.5.2）プライベートフィールドへのアクセスのタイプではなく、インスタンス上で述べています。私はこれについて同僚と話し合っており、（同じインスタンスへのアクセスを制限するのではなく）このように機能する理由を考え出そうとしています。

考えられる最良の引数は、クラスがプライベートフィールドにアクセスして別のインスタンスとの等価性を判断する可能性がある等価性チェックです。他に理由はありますか？それとも、このように機能しなければならない、または何かが完全に不可能であることを絶対に意味するいくつかの黄金の理由？

このように機能する理由の1つは、アクセス修飾子がコンパイル時に機能するためです。そのため、特定のオブジェクトが現在のオブジェクトでもあるかどうかを判断することは簡単ではありません。たとえば、次のコードを考えてみます。

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

コンパイラotherが実際にそれを理解できるのthisでしょうか？すべての場合ではありません。これでコンパイルできないはずだと主張する人もいますが、これは、正しいインスタンスのプライベートインスタンスメンバーにアクセスできないコードパスがあることを意味します。

唯一の問題は扱いやすいだけでなく、それはのように思える状況作りであることをタイプレベルではなく、オブジェクトレベルの可視性を必要性を保証すべき仕事、実際に仕事を。

編集：この推論が逆であるというダニレル・ヒルガースのポイントにはメリットがあります。言語デザイナーは必要な言語を作成でき、コンパイラー作成者はそれに準拠する必要があります。そうは言っても、言語設計者は、コンパイラー作成者が自分の仕事を簡単に行えるようにするインセンティブを持っています。（この場合でも、プライベートメンバーは（暗黙的または明示的に）経由でのみアクセスできると主張するのは簡単thisです）。

しかし、それが問題を必要以上に混乱させていると私は信じています。ほとんどのユーザー（私も含む）は、上記のコードが機能しない場合、不必要に制限していることに気づくでしょう。結局のところ、これがアクセスしようとしている私のデータです。なぜ私は通らなければならないのthisですか？

要するに、コンパイラーにとって「難しい」ということは、私は誇張しすぎたのではないかと思います。私が実際に乗り越えるつもりだったのは、上記の状況はデザイナーが仕事をしたいもののように思われるということです。

C＃および類似の言語で使用される種類のカプセル化の目的は、メモリ内の異なるオブジェクトではなく、コードの異なる部分（C＃およびJavaのクラス）の相互依存性を低くすることです。

たとえば、別のクラスのいくつかのフィールドを使用する1つのクラスでコードを記述する場合、これらのクラスは非常に密に結合されています。ただし、同じクラスの2つのオブジェクトがあるコードを処理している場合、追加の依存関係はありません。クラスは常に自分自身に依存しています。

ただし、カプセル化に関するこのすべての理論は、誰かがプロパティ（またはJavaのget / setペア）を作成し、すべてのフィールドを直接公開するとすぐに失敗し、クラスがフィールドにアクセスしているかのように結合されます。

_{*カプセル化の種類については、Abelの優れた回答を参照してください。}

この興味深いスレッドにはかなりの数の回答が既に追加されていますが、この振る舞いが現状のままである理由については、本当の理由はわかりませんでした。試してみましょう：

過去に戻って

80年代のSmalltalkと90年代半ばのJavaの間のどこかで、オブジェクト指向の概念が成熟しました。クラスのすべてのデータ（フィールド）はプライベートであり、すべてのメソッドはパブリックであるため、もともとOOだけが利用できる概念（1978年に最初に言及）とは考えられていなかった情報の非表示は、Smalltalkで導入されました。90年代のOOの多くの新しい開発の間に、ベルトランドマイヤーは、彼の画期的な本であるオブジェクト指向ソフトウェア構築（OOSC）でOOの概念の多くを形式化しようとしました。 。

プライベートビジビリティの場合

Meyer氏によると、定義されたクラスのセット（192〜193ページ）でメソッドを使用できるようにする必要があります。これにより、非常に詳細な情報の非表示が明らかになります。次の機能は、classAとclassBおよびそのすべての子孫で使用できます。

feature {classA, classB}
   methodName

彼の場合private、次のように述べています。型をそれ自体のクラスに可視であると明示的に宣言しないと、修飾された呼び出しでその機能（メソッド/フィールド）にアクセスできません。つまりx、が変数の場合、x.doSomething()許可されません。もちろん、クラス自体の内部で無資格のアクセスが許可されます。

つまり、同じクラスのインスタンスによるアクセスを許可するには、そのクラスによるメソッドアクセスを明示的に許可する必要があります。これは、instance-privateとclass-privateと呼ばれることもあります。

プログラミング言語でのインスタンスプライベート

クラスプライベートの情報非表示とは対照的に、インスタンスプライベートの情報非表示を使用する、現在使用中の少なくとも2つの言語を知っています。1つは、メイヤーが設計した言語であるエッフェルであり、OOを極限まで引き上げます。もう1つはRubyで、現在でははるかに一般的な言語です。Rubyでは、「このインスタンスにプライベート」をprivate意味します。

言語設計の選択肢

instance-privateを許可することはコンパイラーにとって困難であることが示唆されています。メソッドへの修飾された呼び出しを許可または禁止することは比較的簡単なので、私はそうは思いません。プライベートメソッドdoSomething()が許可されている場合と許可されてx.doSomething()いない場合、言語デザイナーはプライベートメソッドとフィールドに対してインスタンスのみのアクセシビリティを効果的に定義しています。

技術的な観点からは、どちらかを選択する理由はありません（特に、Eiffel.NETがILでこれを行うことができると考えると、多重継承があっても、この機能を提供しない固有の理由はありません）。

もちろん、これは好みの問題であり、すでに述べたように、一部のメソッドは、プライベートメソッドとフィールドのクラスレベルの可視性の機能がないと作成が難しい場合があります。

C＃がクラスのカプセル化のみを許可し、インスタンスのカプセル化を許可しない理由

インスタンスのカプセル化に関するインターネットスレッド（言語がクラスレベルではなく、インスタンスレベルでアクセス修飾子を定義することを指す用語として使用される場合があります）を見ると、この概念はよく見過ごされます。ただし、一部の最近の言語では、少なくともプライベートアクセス修飾子に対してインスタンスのカプセル化を使用していることを考えると、それは、現在のプログラミングの世界で可能であり、実用的であると考えるようになります。

ただし、C＃はその言語設計についてC ++とJavaを最も厳しく見ていました。EiffelとModula-3も画像に含まれていますが、Eiffelの多くの機能がないこと（多重継承）を考慮すると、プライベートアクセス修飾子に関しては、JavaやC ++と同じルートを選択したと思います。

Eric Lippert、Krzysztof Cwalina、Anders Hejlsberg、またはC＃の標準に取り組んでいる他の誰かを手に入れようとする理由を本当に知りたい場合は、残念ながら、注釈付きのC＃プログラミング言語に明確な注釈はありませんでした。

これは私の意見にすぎませんが、実用的には、プログラマーがクラスのソースにアクセスできる場合、クラスインスタンスのプライベートメンバーにアクセスすることで合理的に信頼できると思います。プログラマが彼らの左側にすでに王国への鍵を与えているのに、なぜプログラマを右手を縛るのか？

実際の理由は、等価性チェック、比較、複製、演算子のオーバーロードです...たとえば、複素数にoperator +を実装するのは非常に難しいでしょう。

まず最初に、プライベート静的メンバーはどうなりますか？静的メソッドでのみアクセスできますか？あなたは確かにそれを望んでいないでしょう。それはあなたが自分のにアクセスすることができないからですconst。

あなたの明確な質問に関して、StringBuilderそれ自身のインスタンスのリンクされたリストとして実装されるの場合を考えてください：

public class StringBuilder
{
    private string chunk;
    private StringBuilder nextChunk;
}

自分のクラスの他のインスタンスのプライベートメンバーにアクセスできない場合は、次のように実装する必要がありますToString。

public override string ToString()
{
    return chunk + nextChunk.ToString();
}

これは機能しますが、O（n ^ 2）です-あまり効率的ではありません。実際、それはおそらくStringBuilder、そもそもクラスを持つという目的全体を打ち負かすことでしょう。自分のクラスの他のインスタンスのプライベートメンバーにアクセスできる場合ToStringは、適切な長さの文字列を作成し、文字列内の適切な場所に各チャンクの安全でないコピーを行うことで実装できます。

public override string ToString()
{
    string ret = string.FastAllocateString(Length);
    StringBuilder next = this;

    unsafe
    {
        fixed (char *dest = ret)
            while (next != null)
            {
                fixed (char *src = next.chunk)
                    string.wstrcpy(dest, src, next.chunk.Length);
                next = next.nextChunk;
            }
    }
    return ret;
}

この実装はO（n）であり、非常に高速になり、クラスの他のインスタンスのプライベートメンバーにアクセスできる場合にのみ可能です。

これは多くの言語で完全に合法です（1つはC ++）。アクセス修飾子は、OOPのカプセル化の原則に基づいています。外部へのアクセスを制限するという考え方です。この場合、外部は他のクラスです。たとえば、C＃のネストされたクラスは、その親のプライベートメンバーにもアクセスできます。

これは言語デザイナーの設計上の選択ですが。このアクセスの制限は、エンティティの分離に大きく貢献することなく、いくつかの非常に一般的なシナリオを複雑にする可能性があります。

ここで同様の議論があります

データが各インスタンスにプライベートであるという別のレベルのプライバシーを追加できなかった理由はないと思います。実際、それは言語に完全性の良い感じを与えるかもしれません。

しかし、実際には、それが本当に役立つとは思えません。ご指摘のとおり、通常のプライベート性は、等価性チェックや、Typeの複数のインスタンスに関連する他のほとんどの操作などに役立ちます。ただし、データの抽象化を維持することについては、OOPの重要なポイントであるため、その点も気に入っています。

このようにアクセスを制限する機能を提供することは、OOPに追加する優れた機能になると思います。本当に便利なのでしょうか？クラスはそれ自体のコードを信頼できるはずなので、私はノーと言います。そのクラスはプライベートメンバーにアクセスできる唯一のものであるため、別のクラスのインスタンスを処理するときにデータの抽象化が必要になる本当の理由はありません。

もちろん、インスタンスにプライベートを適用する場合と同じように、いつでもコードを記述できます。通常のget/set方法でデータにアクセス/変更します。これにより、クラスが内部で変更される可能性がある場合に、コードが管理しやすくなります。

上記の素晴らしい答え。この問題の一部は、クラス自体の内部でのインスタンス化がそもそも許可されているという事実であると付け加えます。たとえば、再帰ロジックの "for"ループでは、再帰を終了するロジックがある限り、そのタイプのトリックを使用するためです。しかし、そのようなループを作成せずに同じクラスをインスタンス化または内部に渡すと、論理的には広く受け入れられているプログラミングパラダイムであるにもかかわらず、独自の危険が生じます。たとえば、C＃クラスは、デフォルトのコンストラクターでそれ自体のコピーをインスタンス化できますが、それによって規則が破られたり、因果ループが作成されたりすることはありません。どうして？

ところで...これと同じ問題は「保護された」メンバーにも当てはまります。:(

ほとんどのプログラマーがこの問題のような問題が発生して人々を混乱させ、プライベートメンバーを持つ理由全体を無視するまで完全に把握できない一連の問題とリスクがまだあるため、そのプログラミングパラダイムを完全に受け入れたことはありません。

C＃のこの「奇妙で奇抜な」側面は、優れたプログラミングが経験やスキルとは何の関係もないが、トリックやトラップを知っているだけで、自動車での作業と同じように、もう1つの理由です。ルールが破られることを意図していたという主張は、どの計算言語にとっても非常に悪いモデルです。

データが同じタイプの他のインスタンスにプライベートである場合、それは必ずしも同じタイプであるとは思えないようです。他のインスタンスと同じように動作または動作しないようです。そのプライベートな内部データに基づいて、動作を簡単に変更できます。それは私の意見に混乱を広げるだけです。

大まかに言って、私は個人的に、基本クラスから派生したクラスを作成することで、「インスタンスごとにプライベートデータを保持する」と同じような機能を提供できると思います。代わりに、「一意の」タイプごとに新しいクラス定義があります。