给定场景的适当模式

Question

我正在为存在以下实体的服务开发 .NET 包装器：

• 根属性名称、文件、文件夹、项目
• 项目属性名称、方法创建、重命名、删除
• 文件属性名称、方法创建、重命名、删除
• 文件夹属性名称、文件、文件夹、方法创建、重命名、删除

如您所见，根实体（即单例）可以保存一些文件、文件夹和项目。项目只能由 Root 持有，不能存在于任何文件夹中。另一方面，文件和文件夹可以由根和文件夹实体持有。

我正在尝试找出将这种情况投射到代码中的最佳方式。

Service.Root 将是一个单例属性，可能没有更多的东西了。

Service.Root.Files & Service.Root.Folders - 我应该为此目的制作文件和文件夹类的自定义集合吗？如果是，我是否应该仅通过这些集合上的方法创建文件和文件夹类的新实例？或者我应该允许开发人员通过为它创建一个公共构造函数来创建文件/文件夹而不显式引用服务？我猜不是？因为例如重命名文件会调用与网络一起使用的 Service 上的方法。那么文件、项目和文件夹的每个实例都应该引用服务吗？

这个问题可能很混乱，但我不知道如何解释，对不起。一般来说，我问的是制作文件/项目/文件夹类型的自定义集合是否是个好主意，或者公开通用集合是否更好。此外，如果您知道我的意思，这些公开的集合是否应该是只读的并通过调用 Service.CreateNewFile() 而不是 Service.Folders[0].Add(New File()) 创建新文件。

感谢您提供讨论此类开发模式的任何努力和/或良好链接。

亚伦

Answer 1

您可以同时使用两者来实现您的目标。将集合公开为属性将为用户提供最灵活和熟悉的界面。但是，对集合进行更多控制，将它们公开为只读属性，然后提供添加、删除等方法，将为类设计者提供更多控制权。这可能会导致更少的问题，因为只能通过有限的接口访问集合。 因此，您的权衡是灵活性与控制之间的一种。两种方法都可以。