何时使用枚举、类或标签？答案

【问题标题】：When to use enum, class or tags?何时使用枚举、类或标签？
【发布时间】：2011-11-15 06:05:13
【问题描述】：

假设您有一个特定页面类型的页面（例如普通页面、帐户页面等）。页面由 Page 对象表示。

我的问题是，如何为页面分配页面类型？

我看到了这些选项：

通过使用在 Page 对象中设置的 PageType 枚举。
通过使用 PageType 类，并在 Page 对象中分配它的实例。
通过使用页面标签，这是与页面对象关联的简单字符串。

选项 1 是纯代码方法，因此添加新页面类型意味着更改（核心）代码。选项 2 更灵活，但必须维护这些页面类型会产生额外的开销。选项 3 非常灵活，因为无需维护，并且可以扩展到页面类型以外的其他机制。但是你可以很容易地破坏事情，因为没有限制。

选择一个而不是另一个的其他客观原因是什么？

【问题讨论】：

您希望应用程序的用户能够添加新的页面类型，还是有固定数量的类型？每个页面都只有一种类型，还是您希望页面共享两种或更多类型？
用户不能添加页面类型，如果创建页面，他可以在现有页面类型中进行选择。然而，Web 开发人员可以定义新的页面类型；并在某些小部件中使用它来做出决定。

标签： c# design-patterns architecture enums tags

【解决方案1】：

缺乏关于系统设计和页面要求的详细信息，支持的不同页面类型的数量以及页面本身之间的差异，因此很难做出这样的决定。在这种情况下，我会推荐keep it simple 并使用Enum。

如果页面有自己特定的业务逻辑，您可以坚持使用每个页面类型的类，但只有在真正的页面特定逻辑存在时才谨慎使用。
考虑一下 UserControl/CustomControl 功能（假设您使用的是ASP.NET），这样您就可以通过一组负责页面功能的控件来拆分页面，这样您就可以保留Single Responsibility Principle 和构建耦合较少的系统。
一些逻辑应该是 extracted 从 Page 实体本身到外部助手/工厂/存储库中，然后注入到 Page 类中。

关于目标，您应该定义潜在的页面数量以及应该提供的灵活性级别。还要牢记系统的可扩展性和维护等事项。

【讨论】：

【解决方案2】：

选项 4 怎么样？

创建具有基本页面行为的（抽象）基类，并为每个特定页面创建一个子类。如果您期望在许多不同的地方存在差异，这是最好的设计。它避免了编写switch 语句来评估几十个地方的枚举。

防止使用“魔术”字符串，因此绝对更喜欢使用方法 1 或 2 而不是 3。根据您的要求，使用 the strategy pattern 插入不同的行为也是一个可行的选择。这提供了更大的灵活性，但是初始化你的类会变得有点麻烦。当然，这种行为也可以封装在一个类/工厂方法中，为您完成这项工作。

【讨论】：

【解决方案3】：

以上都不是。

显而易见的问题是为什么您只想识别页面类型？标识本身没有用。您很可能希望对页面做更多的事情。

我会为各种页面创建接口，例如IAccountingPage，然后拥有某种存储库。如果您需要在显示页面之前对其进行预处理，请创建一个过滤器接口，如IPagePreFilter<T> where T : IPage，然后像这样实现它：

public class DiscountFilter : IPagePreFilter<ISalesPage>
{
    public void Process(ISalesPage page)
    {
        if (page.Product.Id == 1234)
            page.AddParagraph("Product is at amazing 50% off");
    }
}

总结：不要尝试将页面识别为具有if (page.PageType == PageEnum.Accounting) bla bla 之类的逻辑，因为它违反了 Liskovs 替换原则。像我建议的那样做一个更强大的解决方案。

【讨论】：