开/闭原理-如何处理这个开关？

Question

我一直在研究开放封闭原则，听起来不错，所以我想实践它的教义。 我考虑将新发现的知识应用到现有项目中，但很快就陷入了困境。

如果出现新的 UserType（这很可能），则需要更改它，但尚未关闭修改。怎么能绕过这个呢？

从我读到的内容来看，听起来我应该在这里实现一个工厂而不是应用 OCP？

打破开闭原则的工厂

 private void BuildUserTree(User user)
    {
        switch (user.UserType)
        {
            case UserType.FreeLoader:
                BuildFreeLoaderTree();
                break;
            case UserType.Premium:
                BuildPremiumTree();
                break;
            case UserType.Unlimited:
                BuildUnlimitedTree();
                break;
            default:
                throw new Exception("No UserType set");

        }
    }

谢谢， 科汉

Answer 1

与任何“原则”一样，OCP 并不是您在所有情况下都必须遵守的规则。

我们被告知“优先选择组合而不是继承”，然而像装饰器和复合这样的模式公开地促进了继承。

类似地，我们被告知“对接口进行编程，而不是实现，但是，在我们的应用程序中的某个时刻，我们将不得不实例化某种描述的具体对象。”

您的解决方案是经典的工厂惯用法（如果不是完整的工厂方法或抽象工厂模式）。这就是它的目的。尝试对其应用 OCP 是没有意义的。

事实上，通过创建此方法，您实际上可以在代码库的其他部分中促进 OCP。既然您已经分离了创建，那么应用程序中的一些其他类现在可以遵守 OCP。

Answer 2

我会做如下：

abstract class User {
   .
   .
   .
   abstract public void buildTree
}

class FreeLoaderUser: User {
   override public void buildTree()
   {
   }
}

class PremiumUser: User {
   override public void buildTree()
   {
   }
}

 class UnlimitedUser: User {
   override public void buildTree()
   {
   }
}

然后，而不是每次添加新用户类型时都需要修改的方法和开关案例，只需调用：

user.buildTree();

然后，每当您需要添加新用户类型时，您都可以扩展代码而不是修改。您只需为新用户类型添加一个新类，而无需触及以前的类。

这就是他们所说的开放封闭，当你可以设法处理它时，为什么要违反它呢？

Answer 3

internal class UserTreeBuilder
{
    [ImportMany(AllowRecomposition=true)]
    public IEnumerable<IBuilder> Builders{ get; set; }

    public UserTreeBuilder()
    {
        // Load all builders from a MEF CompositionContainer
    }

    public void BuildUserTree(User user)
    {
        var builder = Builders.FirstOrDefault(b => b.CanHandleUserType(user.UserType));
    
        if(builder == null)
        {
            throw new Exception("No UserType set");
        }else{
            builder.BuildTree();
        }
    }
}

可用构建器列表可以使用 MEF MEF，从 Codeplex 迁移

Answer 4

要消除类型切换，您必须将职责移回需要类型特定操作的类型。这种类型（在您的情况下为“用户”）拥有有关其自身的所有信息，并且可以根据这些知识轻松调用正确的操作。而且你必须利用继承。

在您的情况下，您必须通过简单继承或组合来反映用户类型。您的“User”将拥有一个属性“UserType”，就像在您的示例中一样，但它不是只是一个“Enum”之类的类型，而是成为一个继承“IUserType”接口并知道如何构造其特定类型的复杂类型依赖项（“UserType”实现“IUserType”）。 “IUserType”可以通过属性公开类型特定的属性（例如返回“ITypeSpecificTree”的“IUserType.TypeSpecificTree”）。

因此，当在您的示例中将“用户”升级为高级时，您只需将该属性设置为具体“IUserType”实现（例如 PremiumUserType”）的新实例，该实例执行其特定操作，例如构建高级树（“ITypeSpecificTree”） “实现）从您的示例以及构造关联类型。

这样，通过使用组合和继承消除了 switch 语句。我们将复杂的“UserType”属性转换为一个单独的类，然后将类型特定的职责移至类型本身。
继承，尤其是依赖倒置有助于在不知道具体类型的情况下对对象进行操作（例如获取用户类型特定信息，如（User.IUserType.IUserSpecificTree“）。这有助于确保我们开放扩展易于修改。

如果我们需要更改特定于类型的树的生成方式或该用户类型的行为方式，我们只需更改即可。触摸关联的“IUserType”如果添加了新的用户类型（扩展），则它们必须实现基本接口“IUserType”，并且不需要触及其他代码（例如 switch 语句）才能使其正常工作，并且不再需要任何类型。需要检查。
为了使其完整并提供更多的可扩展性，“User”类还应该实现一个接口，例如公开用户类型（例如“IUser.IUserType”）的“IUser”。