内部型は優れたAPI設計を妥協しますか？

Question

私は、いつも私が内部の呼び出しやタイプに遭遇したように見えます。

オープンソースのようなコードでアクセス可能であっても、APIコード自体では使用できないと感じています。すなわち、それはあたかも彼らが修正されるのが嫌にされているかのようです。

絶対に必要でない限り、内部キーワードを使用しないでください。

私はこれにオープンソースAPIを求めています。しかし誰もがAPIを変更したいとは思っていませんが、主にそれを使ってアプリケーション自体のコードを作成します。

Answer 1

パブリックAPIの一部ではない内部型をDLLに持つことは何も問題ありません。実際には、内部型（または少なくとも非公開型）を持たない場合は、軽微なDLL以外のものがあれば、悪い設計の兆候である可能性が高くなります

なぜですか？パブリックAPIは、消費者が使用するオブジェクトモデルの部分を公開する方法です。完全にパブリックなタイプのAPIを持つということは、コンシューマに文字通りDLL内のすべてを見させることを意味します。

そのスタンスに沿ったバージョン管理の問題を考えてみましょう。あなたのオブジェクトモデルの文字通り何かを変えることは、大きな変化です。内部型を使用すると、消費者の変化を逃さずにモデルに大きな柔軟性を与えることができます。

Answer 2

APIはパブリックタイプとメンバで構成されていますが、それ以外は実装の詳細です。

これは、内部型は、特にAPIからインターフェイス型を返すときや、それらのインターフェイスを実装するために使用した具体的な型を公開したくない場合に非常に便利だと思います。これにより、APIデザイナーは多くの柔軟性を得ることができます。

Answer 3

内部型は、明示的にAPIから保護されることを意図した型です。あなたは、人々に見せたくないものだけを内部にマークする必要があります。

私の推測では、内部型であるが、パブリックAPIに貴重な付加価値があったと思います。私はかなりのプロジェクトでこれを見てきました。これは別の問題ですが、プライベートタイプが公開されているべきかどうかと同じ問題です。

一般的に、良いプロジェクトはに内部型または非公開型があります。パブリックAPIを拡張することなく、必要な機能セットを実装するのに役立ちます。必要な機能セットを提供するためにパブリックAPIをできるだけ小さく保つことは、ライブラリを使用可能にするための一部です。