我正在构建一个事件调度程序框架,它解码消息并回调用户代码.我的C背景表明我写道：
class Handler:
def onFoo(self):
pass
def onBar(self):
pass
class Dispatcher:
def __init__(self):
self.handler = Handler()
def run():
while True:
msg = decode_message() # magic
if msg == 'foo':
handler.onFoo()
if msg == 'bar':
handler.onBar()
然后框架用户会写如下：
class MyHandler(Handler):
def onFoo(self):
do_something()
dispatcher = Dispatcher()
myHandler = MyHandler()
dispatcher.handler = myHandler
dispatcher.run()
但我也可以设想将onFoo()和onBar()作为Dispatcher的方法,并让用户用其他方法替换它们.然后用户的代码看起来像：
def onFoo():
do_something()
dispatcher = Dispatcher()
dispatcher.onFoo = onFoo
我也可以让Dispatcher.onFoo成为一个callables列表,这样用户就可以在C#中附加多个处理程序.
什么是最恐怖的方式呢？
最佳答案
我不会说第一种方式有什么特别的错误,特别是如果你想在运行时允许Dispatcher对象以有组织的方式自定义(即通过将不同类型的Handler对象传递给它们),如果你的处理程序需要与复杂的状态进行交互和维护.
但是你通过这种方式定义一个基本的Handler类并没有真正获得任何东西;一个类仍然可以继承Handler,而不会覆盖任何方法,因为这不是一个抽象的基类 – 它只是一个常规的基类.因此,如果有一些合理的默认行为,我建议将它们构建到Handler中.否则,您的用户根本无法从Handler获得任何东西 – 他们也可以定义自己的Handler类.虽然如果你只是想提供一个无操作占位符,那么这个设置就可以了.
在任何情况下,我个人更喜欢你建议的第二种方法;我不确定这两者是否更“pythonic”,但第一个对我来说似乎更简洁,因为它将Handler和Dispatcher逻辑分开. (它避免了你在线程中看到的那种情况.线程你只能安全地覆盖一些方法 – 我总是发现有点刺耳.)
但我觉得我应该指出,如果你真的想要一个真正的抽象基类,你应该写一个！从2.6开始,Python为灵活的abstract base classes提供了很多很好的功能.例如,您可以使用abstractmethod装饰器定义一个抽象方法,以确保它必须被子类覆盖;但您也可以定义不必重写的常规方法.如果你正在寻找一个C语言的Pythonic版本,这可能是最好的方式 – 当然,这不是一回事,但它比你现在的更接近.