【发布时间】:2011-07-28 17:42:51
【问题描述】:
我发现元类的存在和使用可以通过为类创建过程提供一个优雅的句柄,从而使您免于编写大量代码。我在我的应用程序中使用它,其中实例化了几个交互服务器。详细说明:
每个设备都实例化一个特定于其操作的服务器类,它是(...的子类)的子类,最终是BaseServer 类。现在,有些设备服务器需要ThreadedTCPserver,有些需要SimpleTCPServer(模块:socketserver)。它们不能都派生自同一个类,因为使用ThreadingMixin 会覆盖SimpleTCPServer 的行为。
为了处理这个动态类配置,我创建了一个MetaServerType,它将BaseServer 的基类选择为(SimpleTCPServer,) 或(ThreadedTCPServer,) --> 生成我想要的动态配置服务器类的结果! (呜呼)
现在,我的问题来了: 我想使用一个存储参数的配置文件,这些参数默认由 MetaServerType 使用。例如:config.default_loglevel 或 config.default_handler 等。并且可以根据元类规范覆盖各个服务器(从命令行或其他方式)。
只有一个配置对象的实例通过程序流传递是一种好的设计实践吗?一种方法是在元类的类主体中初始化配置对象——但我的程序流程从其他地方开始,这意味着元类被多次调用,从而产生各种配置实例。似乎在导入时调用了元类(?)
所以非常欢迎详细回答:
- 如何为元类提供配置信息?
- 让单个配置实例通过程序流进行编辑、更新甚至最终编写的好方法是什么?
- 元类的输入参数能否以某种方式扩展到
Metaclass.__new__(meta, name, bases, attrs)之外?- 额外问题:这是否会让我们更接近(服务器的)有限状态机,从而可以“暂停”或“恢复”状态(而不是实例)?
【问题讨论】:
-
简短回答:没有什么能阻止您将 metaclass 添加到一个本身用作另一个元类的类中。所以简短的回答是“是”。我现在将阅读您的完整问题。
-
对我来说,一个简单问题的解决方案听起来很奇怪。如果他们不知道哪个服务器,为什么您的课程甚至从某些服务器继承?简单的聚合或混合似乎是一种更好的方法。
标签: python configuration metaclass finite-automata