可能な限りブラックボックスを信じています。プログラマーとして、システムに簡単にドロップして動作させることができる、明確に定義されたブラックボックスが必要です。値を与え、適切なメソッドを呼び出して、そこから結果を取得します。
そのために、クラスが機能するために公開する必要がある機能だけを教えてください。
エレベーターを考えてみましょう。フロアに移動するには、ボタンを押します。これは、エレベータを目的の階に到達させるために必要なすべての機能をアクティブにするブラック ボックスへのパブリック インターフェイスです。
あなたがしたことはまさにあなたがすべきことです。クラスに可能な限り最小限の可視性を与えます。一体、本当にやりたいのであれば、すべてを internal（せいぜい）作成してInternalsVisibleTo属性を使用できるので、機能を分離することはできますが、それでも未知の外の世界にさらすことはできません。
公開する唯一の理由は、プロジェクトを複数のDLLやEXEにパッケージ化していて、（何らかの理由で）使用したくないInternalsVisibleToか、サードパーティが使用するライブラリを作成していることです。ただし、サードパーティが使用するライブラリであっても、可能な限り「表面積」を減らすようにしてください。利用できるクラスが多いほど、ライブラリが混乱します。
C＃では、可能な限り最小限の可視性を使用していることを確認する1つの良い方法は、必要になるまで可視性修飾子を省略しておくことです。C＃のすべては、デフォルトで可能な限り可視性が低くなります。クラスの場合は内部、クラスメンバーと内部クラスの場合はプライベートです。
私はあなたが内部のクラスとメンバーの側で誤りを犯すべきだと思います。アイテムの可視性はいつでも上げることができますが、減らすと問題が発生する可能性があります。これは、他の人のためのフレームワークを構築している場合に特に当てはまります。
便利な機能をユーザーから隠さないように注意する必要があります。.NET BCLには、リフレクションに頼らなければ使用できない便利な方法がたくさんあります。ただし、これらの方法を非表示にすることにより、テストおよび保守が必要なものの表面積が減少します。
public私は、顧客にクラスを明示的に消費させたくない場合を除いて、 クラスにマークを付けることを避けたいと思っています。また、クラスをサポートする準備ができています。
クラスをとしてマークする代わりにinternal、アクセシビリティを空白のままにします。このように、public注目に値するものとして目に目立ちます。（もちろん、例外はネストされたクラスであり、同じアセンブリ内でも表示されるようにするには、マークを付ける必要があります。）
ほとんどのクラスは である必要がありますがinternal、ほとんどの非プライベート メンバーは である必要がありますpublic。
メンバーについて尋ねるべき質問は、「クラスが作成された場合、public公開されるメンバーをメンバーにしたいですか?」です。publicアクセス可能なメンバーを持たないクラスはあまり役に立たないため
、通常、答えは「はい (そう)」です。internalメンバーには役割があります。それらは、同じ集会に住む近親者のみを対象とした「裏口アクセス」です。
クラスが内部のままであっても、フロントドア メンバーとバックドア メンバーを確認できると便利です。また、それを public に変更したとしても、戻ってどれがどれであるかを考える必要はありません。
PrivateではなくInternalを使用する必要がある理由はありますか？内部にはアセンブリレベルのスコープがあることに気づきました。つまり、内部クラス/メンバーは、マルチクラスアセンブリ内のすべてのクラスにアクセスできます。
他のいくつかの回答が述べているように、実際に内部/保護/パブリックが必要な場合を除いて、一般に可能な限り最高レベルのカプセル化（つまりプライベート）を選択します。
それらをできるだけ見えるようにする必要がありますが、上記のMikeが述べたように、これによりUserControlsで問題が発生し、フォームまたは他のUserControlsでこれらのコントロールを使用してVSDesignerを使用できます。
したがって、原則として、Designerを使用して追加しないすべてのクラスとUserControlは、必要なだけ表示されるようにしてください。ただし、Designerで使用するUserControlを作成する場合（同じアセンブリ内にある場合でも）、UserControlクラス、そのデフォルトコンストラクター、およびすべてのプロパティとイベントがパブリックに公開されていることを確認する必要があります。デザイナーがそれを操作します。
最近、UserControl MyControlがコンストラクターとともに内部としてマークされたため、デザイナーがthis.myControl = new MyControl（）行をInitializeComponent（）メソッドから削除し続けるという問題が発生しました。
これは本当にバグだと思います。内部としてマークされていても、Designerに追加するためにツールボックスに表示されるため、Microsoftはパブリックコンストラクターでパブリックコントロールのみを表示する必要があるか、内部コントロールで機能するようにする必要があります。良い。
他のクラスへの公開はできるだけ少なくする傾向があり、公開する対象とその理由について慎重に検討する必要があります。
可能な限り内部クラスを使用する問題を発見しました。その型 (またはパラメーターの型や戻り値の型) のメソッド、プロパティ、フィールドなどを内部よりも見やすくすることはできません。これにより、プロパティだけでなく、内部のコンストラクターも作成されます。これは問題にならないはずですが、実際のところ、Visual Studio と xaml デザイナーを使用すると問題が発生します。メソッドがパブリックではなく、ユーザー コントロールのプロパティがデザイナーに表示されないように見えるため、偽陽性エラーがデザイナーによって検出されます。他の人がすでにそのような問題に陥っているかどうかはわかりません...
私は物事をできるだけ公開しないのが好きです。プライベート、保護、内部、パブリック：クラス、変数、プロパティ、および関数に、すべてが引き続き機能するために必要な最小限の可視性を提供します。
正当な理由がある場合にのみ、そのチェーンの上位にあるものの可視性を公開します。
それを消費するコードをどれだけ制御できるかによって異なります。私の Java 開発では、getter が煩わしいため、デフォルトですべてのものを public final にしています。ただし、いつでもコードベースを変更できるという贅沢もあります。これまで、消費者にコードをリリースする必要があるときは、常にプライベート変数とゲッターを使用していました。
私はこれまでの答えに完全に同意しません。内部は恐ろしい考えであり、別のアセンブリがあなたの型を継承することを妨げたり、回避策が必要になった場合に内部型を使用したりすることさえできないと思います。
今日、System.Data.DataTable の内部に到達するためにリフレクションを使用する必要があり (すべてのチェックを行わずに、データテーブルを超高速で構築する必要があります)、単一の型ではないため、リフレクションを使用する必要がありました。私が利用できました。それらはすべて内部としてマークされました。
デフォルトでは、クラスは c# で internal として作成されます: internal の意味: アクセスは現在のアセンブリに制限されます。
http://msdn.microsoft.com/en-us/library/0b0thckt.aspxを参照して ください
良い記事 デフォルトのスコープは内部です: http://www.c-sharpcorner.com/UploadFile/84c85b/default-scope-of-aC-Sharp-class/
「デフォルト」を選択しないでください。その特定のクラスの可視性のニーズに最適なものを選択してください。Visual Studioで新しいクラスを選択すると、テンプレートは次のように作成されます。
class Class1
{
}
これはプライベートです（スコープが指定されていないため）。クラスのスコープを指定する（またはプライベートのままにする）のはあなた次第です。クラスを公開する理由があるはずです。