是否应该通过组合或其他方式引入新行为？

Question

我选择使用组合来公开一些新行为，而不是将新对象注入到我的消费者代码中，或者让消费者提供自己的新行为实现。我是否做出了错误的设计决定？

我有新的要求，要求我只需要在某些情况下实施一些特殊行为。我选择定义一个新接口，在一个单独负责执行行为的具体类中实现新接口。最后，在消费者引用的具体类中，我实现了新接口并将其委托给执行该工作的类。

以下是我正在使用的假设...

• 我有一个名为 IFileManager 的接口，它允许实现者管理各种类型的文件
• 我有一个返回 IFileManager 的具体实现的工厂
• 我有 3 个 IFileManager 的实现，这些是 (LocalFileManager 、DfsFileManager、CloudFileManager）
• 我有一个新要求，要求我只需要管理由 CloudFileManager 管理的文件的权限，因此管理权限的行为是 CloudFileManager 所独有的。

下面是引导我找到以下代码的测试：我写了...

[TestFixture]
public class UserFilesRepositoryTest
{
    public interface ITestDouble : IFileManager, IAclManager { }

    [Test]
    public void CreateResume_AddsPermission()
    {
        factory.Stub(it => it.GetManager("cloudManager")).Return(testDouble);

        repository.CreateResume();

        testDouble.AssertWasCalled(it => it.AddPermission());
    }

    [SetUp]
    public void Setup()
    {
        testDouble = MockRepository.GenerateStub<ITestDouble>();
        factory = MockRepository.GenerateStub<IFileManagerFactory>();
        repository = new UserFileRepository(factory);
    }

    private IFileManagerFactory factory;
    private UserFileRepository repository;
    private ITestDouble testDouble;
}

这是我设计的外壳（这只是基本轮廓而不是整个shibang）...

public class UserFileRepository
{
    // this is the consumer of my code...
    public void CreateResume()
    {
        var fileManager = factory.GetManager("cloudManager");
        fileManager.AddFile();

        // some would argue that I should inject a concrete implementation 
        // of IAclManager into the repository, I am not sure that I agree...
        var permissionManager = fileManager as IAclManager;
        if (permissionManager != null)
            permissionManager.AddPermission();
        else
            throw new InvalidOperationException();
    }

    public UserFileRepository(IFileManagerFactory factory)
    {
        this.factory = factory;
    }

    private IFileManagerFactory factory;
}

public interface IFileManagerFactory
{
    IFileManager GetManager(string managerName);
}

public class FileManagerFactory : IFileManagerFactory
{
    public IFileManager GetManager(string managerName)
    {
        IFileManager fileManager = null;
        switch (managerName) {
            case "cloudManager":
                fileManager = new CloudFileManager();
                break;
            // other managers would be created here...
        }

        return fileManager;
    }
}

public interface IFileManager
{
    void AddFile();
    void DeleteFile();
}

public interface IAclManager
{
    void AddPermission();
    void RemovePermission();
}

/// <summary>
/// this class has "special" behavior
/// </summary>
public class CloudFileManager : IFileManager, IAclManager
{
    public void AddFile() { 
        // implementation elided...
    }

    public void DeleteFile(){ 
        // implementation elided...
    }

    public void AddPermission(){
        // delegates to the real implementation
        aclManager.AddPermission();
    }

    public void RemovePermission() {
        // delegates to the real implementation
        aclManager.RemovePermission();
    }

    public CloudFileManager(){
        aclManager = new CloudAclManager();
    }

    private IAclManager aclManager;
}

public class LocalFileManager : IFileManager
{
    public void AddFile() { }

    public void DeleteFile() { }
}

public class DfsFileManager : IFileManager
{
    public void AddFile() { }

    public void DeleteFile() { }
}

/// <summary>
/// this class exists to manage permissions 
/// for files in the cloud...
/// </summary>
public class CloudAclManager : IAclManager
{
    public void AddPermission() { 
        // real implementation elided...
    }

    public void RemovePermission() { 
        // real implementation elided...
    }
}

Answer 1

您添加新行为的方法只是在总体方案中节省了初始化工作，因为无论如何您都将 CloudAclManager 与 CloudFileManager 分开实现。我不同意一些关于如何将其与您现有设计集成的事情（这还不错）......

这有什么问题吗？

1. 您分离了文件管理器并使用了 IFileManager，但没有对 IAclManager 进行同样的操作。当您有一个工厂来创建各种文件管理器时，您会自动将 CloudAclManager 设为 CloudFileManager 的 IAclManager。那么，拥有 IAclManager 有什么意义呢？
2. 更糟糕的是，你
   初始化一个新的CloudAclManager
   每次尝试获取其 ACL 时，都在 CloudFileManager 内部
   经理-你刚刚给了工厂
   对你的责任
   云文件管理器。
3. 除了将其作为属性之外，您还让 CloudFileManager 实现了 IAclManager 。您刚刚将权限对于 CloudFileManager 唯一的规则移至模型层而不是业务规则层。这也导致支持不必要的
   self 和 property 之间循环引用的潜力。
4. 即使你想要
   CloudFileManager 委托
   权限功能
   CloudAclManager，为什么误导别人
   类认为
   CloudFileManager 处理自己的
   权限集？你刚刚做了你的
   模型类看起来像一个门面。

好吧，那么我应该做什么呢？

首先，您将类命名为 CloudFileManager，这是正确的，因为它的唯一职责是管理云文件。既然云的权限集也必须进行管理，那么 CloudFileManager 承担这些新职责真的正确吗？答案是否定的。

这并不是说您不能在同一个类中使用管理文件的代码和管理权限的代码。但是，将该类命名为更通用的名称（例如 CloudFileSystemManager）会更有意义，因为它的职责不仅限于文件或权限。

不幸的是，如果您重命名您的类，则会对当前使用您的类的人产生负面影响。那么，仍然使用组合，但不更改 CloudFileManager 怎么样？

我的建议是执行以下操作：

1。保留您的 IAclManager 并创建 IFileSystemManager

public interface IFileSystemManager {
    public IAclManager AclManager { get; }
    public IFileManager FileManager { get; }
}

或

public interface IFileSystemManager : IAclManager, IFileManager {

}

2。创建CloudFileSystemManager

public class CloudFileSystemManager : IFileSystemManager {
    // implement  IFileSystemManager
    // 
    // How each manager is set is up to you (i.e IoC, DI, simple setters, 
    // constructor parameter, etc.).
    // 
    // Either way you can just delegate to the actual IAclManager/IFileManager
    // implementations.
}

为什么？

这将允许您在使用新行为时对当前代码库/功能的影响最小，而不会影响那些使用原始代码的人。文件管理和权限管理也可以同时进行（即在尝试实际文件操作之前检查权限）。如果您需要任何其他权限集管理器或任何其他类型的管理器，它也是可扩展的。

编辑 - 包括提问者的澄清问题

如果我创建 IFileSystemManager : IFileManager, IAclManager，存储库是否仍使用 FileManagerFactory 并返回 CloudFileSystemManager 的实例？

不，FileManagerFactory 不应返回 FileSystemManager。您的 shell 必须更新才能使用新的接口/类。也许类似于以下内容：

private IAclManagerFactory m_aclMgrFactory;
private IFileManagerFactory m_fileMgrFactory;

public UserFileRepository(IAclManagerFactory aclMgrFactory, IFileManagerFactory fileMgrFactory) {
    this.m_aclMgrFactory = aclMgrFactory;
    this.m_fileMgrFactory = fileMgrFactory;
}

public void CreateResume() {
    // I understand that the determination of "cloudManager"
    // is non-trivial, but that part doesn't change. For
    // your example, say environment = "cloudManager"
    var environment = GetEnvMgr( ... );

    var fileManager = m_fileMgrFactory.GetManager(environment);
    fileManager.AddFile();

    // do permission stuff - see below
}

至于调用要完成的权限，您有几个选择：

// can use another way of determining that a "cloud" environment
// requires permission stuff to be done
if(environment == "cloudManager") {
    var permissionManager = m_aclMgrFactory.GetManager(environment);
    permissionManager.AddPermission();
}

或

// assumes that if no factory exists for the environment that
// no permission stuff needs to be done
var permissionManager = m_aclMgrFactory.GetManager(environment);
if (permissionManager != null) {
    permissionManager.AddPermission();
}

Answer 2

我认为构图正是实现这种技巧的正确手段。但我认为您应该保持更简单（KISS），只需在 IFileManager 中创建一个 IAclManager 属性并将其默认设置为 null 并在那里设置云服务的 SecurityManager 实现。

这有不同的优点：

• 您可以通过对 securityManager 属性进行 null 检查来检查是否需要检查权限。这样，如果不需要完成权限管理（与本地文件系统一样），则不会弹出异常。像这样：

if (fileManager.permissionsManager != null)
    fileManager.permissionsManager.addPermission();

当您执行任务（添加或删除文件）时，您可以再次检查是否有权限管理器以及是否授予了权限，如果没有则抛出异常（因为当缺少执行某项操作的权限，而不是一般情况下缺少权限（如果您不打算添加或删除文件）。

• 当您的客户下次更改需求时，您可以像现在一样为其他 IFileManager 实现更多 IAclManager。

• 哦，那么当其他人查看代码时，您就不会有如此令人困惑的层次结构;-)

Answer 3

总的来说，它看起来不错，但我确实有一些建议。看来您的 CreateResume() 方法实现需要一个 IFileManager，它也是一个 IAclManager （否则它会引发异常）。

如果是这种情况，您可能需要考虑向 GetManager() 方法添加一个重载，在该方法中您可以指定所需的接口，并且工厂可以拥有在找不到正确的接口时抛出异常的代码。文件管理器。为了实现这一点，您可以添加另一个空接口，但同时实现 IAclManager 和 IFileManager：

public interface IAclFileManager : IFileManager, IAclManager {}

然后将以下方法添加到工厂：

public T GetManager<T>(string name){ /* implementation */}

如果给定名称的管理器未实现 T，GetManager 将抛出异常（您也可以检查如果它派生自 T 类型或者也是 T 类型）。

话虽这么说，如果 AddPermissions 不接受任何参数（不确定您是否只是为了这篇文章而这样做），为什么不直接从 CloudFileManager.AddFile() 方法调用 AddPermissions() 并将其完全封装在用户之外（删除是否需要新的 IAclManager 接口）？

无论如何，在 CreateResume() 方法中调用 AddFile 然后抛出异常似乎不是一个好主意（因为您现在创建了一个没有正确权限的文件，这可能是一个安全问题，而且消费者收到异常，因此他可能认为 AddFile 没有成功，而不是 AddPermission）。

祝你好运！