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

Question

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

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

我看到以下选项：

1.通过使用在Page对象中设置的PageType枚举。 2.通过使用PageType类，并在Page对象中分配其实例。 3.通过使用与Page对象关联的简单字符串的页面标记。

选项1是纯代码方法，因此添加新页面类型意味着更改（核心）代码。 选项2更加灵活，但是需要维护这些页面类型会有额外的开销。 选项3非常灵活，因为没有维护并且可以扩展到其他机制而不仅仅是页面类型。 但是，由于没有任何限制，您可能很容易破坏事物。

选择其中一种方案的其他客观理由是什么？

- L-Four

---

你想让应用程序的用户能够添加新的页面类型，还是有固定数量的类型？每个页面都恰好有一个类型，还是你期望页面共享两个或更多类型？ - Doc Brown

用户无法添加页面类型，但如果他创建一个页面，可以在现有页面类型之间进行选择。然而，Web开发人员可以定义新的页面类型，并在某些小部件中使用它来做出决策。 - L-Four

Answer 1

关于系统设计和页面需求的细节缺乏，不清楚需要支持多少种不同类型的页面以及页面之间的差异，因此难以做出这样的决定。在这种情况下，我建议 保持简单 并使用 Enum。

• 如果页面具有自己特定的业务逻辑，则可以按页面类型粘贴类，但只有在确实存在特定于页面的逻辑时才可仔细操作。
• 考虑用户控件/自定义控件功能（假设你正在使用 ASP.NET），这样您可以通过一组控件拆分页面，这些控件负责页面功能的一部分，因此您将保持 单一职责原则 并构建更少耦合的系统。
• 某些逻辑应从页面实体本身提取到外部帮助程序/工厂/存储库中，然后注入页面类中。

关于目标，您应该定义潜在的页面数量以及需要提供多少灵活性。还要考虑系统的可扩展性和维护等因素。

- sll

Answer 2

第四种选项怎么样？

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

避免使用“神奇”的字符串，因此绝对推荐使用方法1或2而不是3。根据您的要求，使用策略模式插入不同的行为也可以是一个可行的选择。这提供了更大的灵活性，但初始化您的类将变得有点繁琐。当然，这种行为再次可以包装在一个类/工厂方法中，为您执行这项工作。

- Steven Jeuris

Answer 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，因为这会违反Liskov替换原则。请使用更健壮的解决方案，如我所建议的那样。

- jgauffin