[注。在将“日历”一系列事件和“事件”(日历上的单个事件)分开时要非常谨慎。在您的问题中,似乎可能存在一些混乱。]
工厂设计模式有很多变体。
一个独立的便利函数(例如,calendarMaker(data))
一个单独的类(例如,CalendarParser),它构建您的目标类(日历)。
一个类级别的方法(例如 Calendar.from_string)方法。
这些有不同的目的。都是 Pythonic,问题是“你是什么意思?” 和“可能会发生什么变化?” 意义就是一切;改变很重要。
便利函数是 Pythonic 的。像 Java 这样的语言不能有自由浮动的函数;你必须在一个类中包装一个孤独的函数。Python 允许你在没有类开销的情况下拥有一个单独的函数。当您的构造函数没有状态更改或替代策略或任何先前操作的记忆时,函数是相关的。
有时人们会定义一个类,然后提供一个方便的函数来创建该类的实例,设置状态和策略的常用参数以及任何其他配置,然后调用该类的单个相关方法。这为您提供了类的状态以及独立函数的灵活性。
使用了类级别的方法模式,但它有局限性。一,它被迫依赖于类级别的变量。由于这些可能会令人困惑,当您需要添加功能(如状态或替代策略)时,作为静态方法的复杂构造函数会遇到问题。请确保您永远不会扩展静态方法。
第二,它与其他类方法和属性或多或少无关。这种from_string
只是您的日历对象的许多替代编码之一。您可能有一个from_xml
, from_JSON
,from_YAML
和 on 和 on 。这些都与日历是什么或它的作用无关。这些方法都是关于如何对日历进行编码以进行传输。
您将在成熟的 Python 库中看到工厂与它们创建的东西是分开的。编码(如字符串、XML、JSON、YAML)受制于大量或多或少的随机变化。然而,基本的东西很少改变。
将两个关注点分开。尽可能让编码和表示远离状态和行为。