c# - 「内部」クラス内に「パブリック」メンバーを含めることは、プログラミングの悪い習慣ですか？

Question

「内部」として宣言されたクラスに「保護」、「内部」、「プライベート」のメンバー（フィールド、メソッド、プロパティ、イベント）のみを保持する場合は、より具体的で適切ではないでしょうか。

私はさまざまなコードでこのプラクティス（「内部」クラスに「パブリック」メンバーを持っている）を見たので、それが悪いプラクティスなのか、それとも何らかの利点や利点があるのか​​を知りたかっただけです。

[C＃のみが気になります]ご関心をお寄せいただきありがとうございます。

Answer 1

必ずしも。暗黙的にインターフェースを実装したい場合は、パブリックメンバーは許容範囲を超えています。

ただし、一般的に、クラスが内部の場合、パブリックメンバーはあまり意味がありません。定義されているモジュールの外部で強く型付けされた方法でクラスを公開することはできないため、怪我をすることはありませんが、インターフェイスを暗黙的に実装していない場合、大きな利点はありません。

Answer 2

クラス自体に内部スコープがある場合でも、これらのパブリック メンバーは引き続きクラスのパブリック インターフェイスの一部であると想定するのが妥当です。クラスのメンバーを見るinternalと、これは「密結合を表現するやや危険なバックドア アクセスですpublicが、私の心の中では適切な防御プログラミングの責任を暗示しています。それは純粋に概念的な違いです。

Answer 3

それが私がしていることです。私の脳が「このメンバーはアクセス可能でなければならない」と考えるとき、私の指は制御不能に公共の場を叩き始めます。クラスを宣言するときは、そのような問題はありません。

1つの大きな利点：内部クラスをパブリックにする（またはその逆が望ましい）リファクタリングでは、1つの単語を変更するだけで済みます。そして、Microsoftもこれを主に行いました。

Answer 4

クラスのinternal仕様はメンバーの宣言のスコープを制限するpublicため、すべてのパブリック メンバーは実際にはinternal. とは言っても、publicは よりもはるかにタイピングが少ないinternalので、私の通常のイディオムは、クラスを として宣言しinternal、公開されたメソッドをとして宣言することpublicです。internalクラスがそうであるかのようにメンバーをマークするだけで、public一部のメンバーを同じアセンブリに制限したい。

Answer 5

私が認識している唯一の機能上の理由は、インターフェイスを暗黙的に実装するためです。publicインターフェイスと一致させるには、すべてのインターフェイス メソッドにタグを付ける必要があります。これは、型またはインターフェイスがパブリックでない場合でも当てはまります。

この限られた状況を除いて、私はその練習が本当に嫌いです。これを行うと、アプリケーションのパブリック サーフェス エリアを grep するのが少し難しくなります。代わりに、より高度な検索を行う必要があります。

さらに、おそらく少し不合理な方法で、メンバーが実際には公開されていないのに公開としてマークされていることは私を悩ませます。

Answer 6

はい、それは悪いプログラミング慣行だと思います。

アクセスを制御するだけではありません。また、コードをよりモジュール化することでもあります。

オブジェクトのデータのコンシューマーがそのオブジェクトのデータの一部を必要とする場合、getterメソッドを呼び出します。後で返されるデータが異なる場合、プログラマーは、そのデータが読み取られたすべての場所ではなく、1つの場所でコードを変更するだけで済みます（メンバーがパブリックの場合）。これは、場所に関するコードをコピーして貼り付けるのではなく、関数/メソッドを記述して呼び出す必要がある理由と似ています。

ここに例を示して説明します：http： //www.programmingincpp.com/private-versus-public-data-members-in-a-class.html

Answer 7

メソッド修飾子を設定すると、クラス アクセス修飾子が変更される可能性を想像してみてください。クラスがパブリックであっても、メソッドを内部にする必要がある場合は、そう言います。そうでない場合、メソッドは public として書き込まれます。