使用抽象类进行事件处理程序回调是惯用Python吗？

我正在构建一个事件调度程序框架,它解码消息并回调用户代码.我的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版本,这可能是最好的方式 – 当然,这不是一回事,但它比你现在的更接近.

使用抽象类进行事件处理程序回调是惯用Python吗？

相关推荐