[C#] デフォルトで内部または公開の可視性を使用する必要がありますか?


Answers

あなたがしたことはまさにあなたがすべきことです。 あなたのクラスにできるだけ目立たない最小限の可視性を与えます。 もしあなたが本当に豚を食べたいのであれば、 すべてを internal (最大限)にしてInternalsVisibleTo属性を使うことができるので、機能を分けることができますが、未知の外界にそれを公開することはできません。

物事を公開する唯一の理由は、プロジェクトをいくつかのDLLやEXEでパッケージ化していることと、何らかの理由でInternalsVisibleTo気にしないこと、またはサードパーティが使用するライブラリを作成していることです。 しかし、第三者が使用する図書館であっても、可能であれば、「表面積」を減らそうとするべきです。 利用可能なクラスが増えるほど、図書館はもっと混乱します。

C#では、最小限の可視性を可能にするための良い方法の1つは、必要になるまで可視性変更子を残すことです。 C#のすべてのデフォルトでは、可視性は最小限に抑えられています。クラスは内部、クラスメンバと内部クラスはプライベートです。

Question

私はかなり新しいC#と.NET開発者です。 私は最近、C#を使用してMMCスナップインを作成しました。これは、特に組織内の他のいくつかの開発者がC ++でどれほど難しいかについて話を聞いた後に、いかに簡単なのかを嬉しく思っていました。

私はずっとずっとプロジェクト全体を見て、スナップインを実行するためにランタイムが必要とする場合を除いて、 "public"キーワードのすべてのインスタンスを "internal"にしました。 あなたが一般的にクラスやメソッドを公開したり、内部的に作成したりする場合、これについてのあなたの気持ちは何ですか?




Privateの代わりにInternalを使用する必要がある理由はありますか? Internalはアセンブリレベルのスコープを持っていることに気づきます。 つまり、内部クラス/メンバーは、マルチクラスアセンブリのすべてのクラスからアクセス可能です。

他の答えが述べたように、内部/保護/公開が実際に必要でない限り、一般的に可能な限り最高レベルのカプセル化(つまりプライベート)に進みます。




それは、それを消費するコードに対してどれだけの制御があるかによって異なります。 私のJava開発では、ゲッタが迷惑であるため、デフォルトですべてのものを公開します。 しかし、私はいつでも自分のコードベースで何かを変更できるという贅沢を持っています。 過去に、私が消費者にコードをリリースしなければならなかった時、私はいつもプライベート変数とゲッターを使いました。




私は可能な限り物事を公開するのが好きです。 プライベート、プロテクト、内部、パブリック:クラス、変数、プロパティ、および関数に、すべてが動作するために必要な可視性を最小限に抑えます。

正当な理由があるときだけ、私はその鎖の上に何かの視認性を公開することになるだろう。




可能な限り表示するようにする必要がありますが、上記のMikeの記述どおり、これはUserControlsの問題を引き起こし、フォームや他のUserControlsのコントロールでVS Designerを使用します。

したがって、一般的なルールとして、追加する予定のないすべてのクラスとUserControlを、Designerを使用して必要なだけ可視に保ちます。 デザイナで使用するUserControlを作成している場合(UserControlクラス、そのデフォルトのコンストラクタ、プロパティ、およびイベントがデザイナに公開されていることを確認する必要があります)それに取り組む。

UserControl MyControlがコンストラクタとともに内部としてマークされているため、デザイナーがthis.myControl = new MyControl()行をInitializeComponent()メソッドから削除し続ける問題が最近発生しました。

そのバグは本当にバグだと思いますが、たとえ内部としてマークされていても、ツールボックスに表示されてデザイナに追加されたとしても、パブリックコンストラクタでパブリックコントロールを表示するだけで済みます。よく







私は、明示的に私の顧客がそれらを消費することを望んでいない限り、クラスをpublicとしてマークすることを避けることを好むし、それらをサポートする用意がある。

クラスをinternalとしてマークするのではなく、アクセシビリティを空白のままにします。 このようにして、 publicは注目に値する何かを目の当たりにしています。 (もちろん、ネストされたクラスは例外で、同じアセンブリ内であっても表示されるようにする必要があります)。