私は職場で製品のコンポーネントを開発しており、そのうちの1つはフローレイアウトパネルに基づいています。System.Designの多くのDesignerクラスが内部としてマークされているのはなぜですか？
私がしたいのは、カスタムデザイナーを提供することですが、それはデフォルトのデザイナー（System.Windows.Forms.Design.FlowLayoutPanelDesigner）によって提供される機能を失うことなくinternalとマークされています。
Reflectorを使用して、私は自分自身を再実装すると思っていました。「FlowPanelDesigner and that from PanelDesigner」を継承しています。これらはすべて内部的なものです。
これらのクラスは、なぜ内部的なマークが付いているのですか？それは、Visual Studio用のものであり、フレームワークコードではないからですか？
また、すべての機能を再実装する方が簡単なオプションがありますか？
ライブラリーのコードを公開するには、高いコストがかかります。 フレームワークライブラリーから公開してください。
Ii は、製品寿命の間、バイナリ（およびソースの可能性が高い）の互換性を維持します。これらのクラスの契約を破棄すると、数百、数千の有料顧客が使用しているウィジェットが破損する可能性が高いことを意味します。
後方互換性を破ることは、MSFTが歴史的にやっていたことです（Foo2、Foo3と呼ばれるインターフェイスの数が目につく、メソッドがBlahとBlahExを呼び出すことを目の当たりにしています）。 彼らは着実にこのような形でかなりの負債を負ってきたので、これらの問題を最初から避けることは、将来このような問題を減らす最も安価な方法であることを認識しています。したがって、新しい公共のapiは、その存在を非常に強く正当化する必要があります。
デザインタイムコードの生成は、ソフトウェアエコシステムのライフサイクル全体にわたる改善を強く求めているエリアの一種です（このエリアの大きな変更のためにVSの部分的なクラス変更を見てくださいが、 ）。このインフラストラクチャに大きく依存するクラスを公開することで、競争上の優位性とみなすインフラストラクチャを変更するための範囲が限定されることになります。
このように、現実的で安全なアプローチは、そのようなクラスを公開することではありません。マイクロソフトの規模と顧客基盤の企業でなくても、私は確かに同じアプローチを取っていただろう。
私は分かりませんが、マイクロソフトの答えは、「これはまさに私たちが作ったやり方です」、あるいは「下位互換性を維持する負担を軽減したかった」と思います。