0

次のエンティティが存在するサービスで .NET ラッパーを開発しています。

  • ルートプロパティ Name、Files、Folder、Items
  • 項目のプロパティ 名前、メソッド 作成、名前変更、削除
  • ファイルのプロパティ 名前、メソッド 作成、名前変更、削除
  • フォルダーのプロパティ 名前、ファイル、フォルダー、メソッド 作成、名前変更、削除

ご覧のとおり、ルート エンティティ (シングルトン) は、いくつかのファイル、フォルダー、およびアイテムを保持できます。アイテムはルートのみが保持でき、どのフォルダーにも存在できません。一方、ファイルとフォルダーは、ルート エンティティとフォルダー エンティティの両方でサポートできます。

このシナリオをコードに投影する最良の方法を見つけようとしています。

Service.Root はシングルトン プロパティになります。おそらくそれ以上のものはありません。

Service.Root.Files & Service.Root.Folders - この目的のために File および Folder クラスのカスタム コレクションを作成する必要がありますか? はいの場合、これらのコレクションのメソッドを介してのみ File および Folder クラスの新しいインスタンスを作成できるようにする必要がありますか? または、開発者がサービスのパブリック コンストラクターを作成して、サービスへの明示的な参照なしでファイル/フォルダーを作成できるようにする必要がありますか? そうじゃないかな?たとえば、ファイルの名前を変更すると、ネットワークで動作するサービスのメソッドが呼び出されるためです。では、File、Item、および Folder のすべてのインスタンスが Service を参照する必要がありますか?

この質問はおそらく非常に厄介ですが、それを説明する方法がよくわかりません。申し訳ありません。一般的に、ファイル/アイテム/フォルダー タイプのカスタム コレクションを作成するのが良い考えなのか、それともジェネリック コレクションを公開する方が良いのかを尋ねています。また、これらの公開されたコレクションは読み取り専用であり、Service.Folders[0].Add(New File()) の代わりに Service.CreateNewFile() を呼び出して新しいファイルを作成する必要があります。

そのような開発パターンについて議論する努力や良いリンクに感謝します。

アーロン

4

1 に答える 1

0

あなたはあなたの目標を達成するために両方の少しを使うことができます。コレクションをプロパティとして公開すると、ユーザーは最も柔軟で使い慣れたインターフェイスになります。ただし、コレクションをより細かく制御し、それらを読み取り専用プロパティとして公開してから、追加、削除などのメソッドを提供することで、クラス設計者はより細かく制御できるようになります。コレクションへのアクセスは限られたインターフェイスを介してのみ発生するため、これにより問題が少なくなる可能性があります。したがって、トレードオフは柔軟性と制御の1つです。どちらのアプローチも機能します。

于 2012-04-08T19:17:19.187 に答える