大規模で複雑なオブジェクト ライブラリ ( ArcObjects )の操作を簡素化するためのフレームワークの作成に直面しています。この種のフレームワークを作成するために、どのようなガイドラインを提案しますか? 静的メソッドが優先されますか? ロギングなどをどのように処理しますか? ベンダーが導入する可能性のある変更に対して、フレームワーク コードを将来どのように証明しますか?
NHibernate、log4net、および NLog やNetTopologySuiteなどのプロジェクトから読んだコードで見たさまざまなラッパーとヘルパーのすべてを考えてみると、非常に多くの優れたアプローチが見られますが、正直なところ、どこから始めればよいか途方に暮れています。 .
ところで - 私は C# 3.5 で作業していますが、それは言語よりも推奨されるアプローチに関するものです。
Brad Abrams のFramework Design Guidelinesブックは、これに関するすべてです。一見の価値があるかもしれません。
より柔軟なコードを書くようにしてください。たとえば、配列をパラメーターとして受け入れるメソッドがある場合、代わりに IEnumerable または IList を受け入れることができますか?
一貫性があることは、どのような慣習に従うかよりも重要だと思います。自分自身の将来を保証する限り、それはフレームワークを作成しているコードの問題です。砂の家よりレンガの家の上に建てる方がはるかに簡単です。
フレームワークのコードを書くことは、アプリケーション コードを書くこととはまったく異なります。
フレームワーク レベルのコードを記述するときは、クラス ライブラリ開発者向けのデザイン ガイドラインを常に参照してきました (他の人にも参照してもらいます) 。