内部クラスでパブリックメソッドを使用する理由は何ですか? 質問する

内部クラスでパブリックメソッドを使用する理由は何ですか? 質問する

私たちのプロジェクトの 1 つには、次のようなコードが大量に含まれています。

internal static class Extensions
{
    public static string AddFoo(this string s)
    {
        if (s == null)
        {
            return "Foo";
        }

        return $({s}Foo);
    }
}

「後で型を公開する方が簡単だから」以外に、これを行う明確な理由はありますか?

これは非常に奇妙なエッジケース (Silverlight での反射) でのみ問題になるか、まったく問題にならないのではないかと思います。

ベストアンサー1

更新:この質問は2014年9月の私のブログのテーマ素晴らしい質問をありがとうございます!

この問題については、コンパイラ チーム内でもかなりの議論が行われています。

まず、ルールを理解しておくことが賢明です。クラスまたは構造体のパブリック メンバーは、その型にアクセスできるすべてのメンバーがアクセスできるメンバーです。したがって、内部クラスのパブリック メンバーは事実上、内部メンバーです。

では、内部クラスがある場合、アセンブリ内でアクセスするメンバーは public または internal としてマークする必要がありますか?

私の意見は、そのようなメンバーを公開としてマークすることです。

「パブリック」は、「このメンバーは実装の詳細ではありません」という意味で使用します。保護されたメンバーは実装の詳細です。派生クラスを機能させるために必要なものがあります。内部メンバーは実装の詳細です。このアセンブリの内部にある他の何かが正しく機能するためには、メンバーが必要です。パブリック メンバーは、「このメンバーは、このオブジェクトによって提供される主要な、文書化された機能を表します」という意味です。

基本的に、私の考え方は、この内部クラスをパブリック クラスにすることにしたとします。そのためには、クラスのアクセシビリティという1 つの点だけを変更する必要があります。内部クラスをパブリック クラスに変更するということは、内部メンバーをパブリック メンバーに変更する必要があることを意味する場合、そのメンバーはクラスのパブリック サーフェス領域の一部であり、最初からパブリックであるべきでした。

反対する人もいます。メンバーの宣言を一目見て、それが内部コードからのみ呼び出されるかどうかをすぐに知ることができるようにしたいと言う人もいます。

残念ながら、これは必ずしもうまくいくとは限りません。たとえば、内部インターフェースを実装する内部クラスでは、実装メンバーがクラスのパブリック サーフェスの一部であるため、実装メンバーを public としてマークする必要があります。

おすすめ記事