这种设计模式合乎逻辑吗？

Question

以下 C# 是抽象的，因此您可以看到我正在尝试完成的结构
这是我用来表示文件系统树的复合 (GoF) 模式

interface IComponent
{
    void Render();
    void Add(INode);
    void Remove(INode);
}

class Folder : IComponent
{
    List<IComponent> filesAndFolders = new List<IComponent>();

    void Render()
    {
        Console.WriteLine("This is a folder, num childs: " + 
    }

    void Add(IComponent add)
    {
        filesAndFolders.Add(add);
    }

    void Remove(IComponent rem)
    {
        filesAndFolders.Remove(rem);
    }
}

class File : IComponent
{
    void Render()
    {
        Console.WriteLine("This is a file");
    }

    void Add(IComponent add)
    {
    //do nothing... cant add folder to file
    }

    void Remove() { } //same as above
}

我对上述代码的问题是现在我的文件没有实现添加或删除...
我可以：

1. 从组件中删除添加和删除，但我相信我有点打破了这种模式。
2. 使用补充模式（装饰器？）更改叶和复合类中的添加。例如，强制 Folder 以某种方式具有方法 Folder.AddFileOrFolder(Component) 和 File 具有 File.AddSibling(File)。
3. 看看不同的模式。也许我做错了，或者在不了解我的要求的情况下试图完成一些不可能的事情？例如，一些问题是我使用的模式是/应该如何与对象的查看交互，以及用户输入如何影响对象。

这些文件和文件夹实际上是远程主机上对象的表示，它们不是硬盘上的实际文件和文件夹。一种用户交互是当应用程序中的“文件”被拖到桌面上时，文件被下载。

奖金（一些相关的）问题：
什么是在我的应用程序中缓存文件的好技巧或技术，以便如果用户确实与“虚拟”文件交互，他们会更快地看到结果。

谢谢。

Answer 1

我建议只使用两个类，Folder 和 File。文件夹有两个集合，文件夹和文件。无需使用不合适的模式使其复杂化。如果文件和文件夹有一些通用方法/属性（例如名称），您可以为共享方法/属性创建适当的接口。

Answer 2

我同意@Brian。我将创建一个包含文件和文件夹信息的界面。

interface IFileSystemItem
{
    string Name {get; set;}

    // folder for files, parent folder for folders, null for root folders.
    IFileSystemItem Parent {get;set;}

    DateTime CreatedAt {get;set;}

    DateTime ModifiedAt {get;set;}

    ISecurityInfo SecurityInfo {get;set;}
}

不要无缘无故地尝试使用模式，只会使事情复杂化。

Answer 3

如果您打算用它来实现访问者模式，那么在这里使用复合模式特别有用。换句话说，随着时间的推移，您可能希望在文件/文件夹结构中添加任意数量的不可预见的活动。例如，您不知道您需要能够检查文件系统中包含对 EnvDTE 的引用的 csproj 文件或计算零长度文件的数量。结合这两种模式很容易。有时这些模式很有用。有时他们会载入史册，因为“看起来有人正在学习一种模式”。通过工程贸易研究考虑更大的业务需求。特别确定是否需要可扩展性或可扩展性并做出决定。

Answer 4

我发现几乎所有使用接口的模式都存在同样的问题。接口方法的调用者无法保证实现者执行特定的任务，或者确实做了任何事情。这让我很不满意，我不确定我是否知道这个哲学问题的令人满意的解决方案。

我的一个想法是期望每个接口方法都返回一个类的实例——这个类应该有一个私有构造函数并且需要某些步骤来创建它，以“证明”创建方法正在做一些相关的事情。这就像一个陌生人（接口实现者是）可以返回给调用者进行验证的工作“报告”。

另一方面，这可能被视为一种反模式，因为接口的意义在于您不关心底层实现。这意味着您必须对代码进行结构化，因此如果它没有暴露预期的行为，那是实现者的问题，而不是调用者的问题。