Question

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

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

我看到了这些选项：

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

选项1是仅代码方法，因此添加新页面类型意味着更改（核心）代码。选项2更灵活，但是必须维护这些页面类型还有额外的开销。选项3非常灵活，因为它没有维护，并且可以扩展到除页面类型之外的其他机制。但是你可以很容易地解决问题，因为没有限制。

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

Answer 1

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

如果页面具有自己的特定业务逻辑，您可以坚持使用每页类型的类，但只有在那里真正特定于页面的逻辑时才能仔细执行。
考虑UserControl / CustomControl功能（假设您使用ASP.NET），这样您就可以通过一组控件来拆分页面，这些控件负责页面功能，所以这样你就可以保持{{ 3}}并建立较少的耦合系统。
某些逻辑应该从Page实体本身extracted到外部助手/工厂/存储库，然后注入Page class。

关于目标，您应该定义可能存在多少页面，以及应该提供哪种程度的灵活性。还要记住诸如系统的可扩展性和维护之类的东西。

Answer 2

选项4怎么样？

创建具有基本页面行为的（抽象）基类，以及每个特定页面的子类。如果你期望在很多不同的地方出现差异，这是最好的设计。它可以防止在几十个地方编写评估枚举的switch语句。

防止使用'魔术'字符串，所以绝对更喜欢使用方法1或2而不是3.根据您的要求，使用the strategy pattern插入不同的行为也是一个可行的选择。这提供了更大的灵活性，但初始化您的课程将变得更加麻烦。当然，这种行为可以再次包含在为您完成此工作的类/工厂方法中。

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之类逻辑的页面，因为它打破了Liskovs替换原则。做一个比我建议的更强大的解决方案。

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

3 个答案: