¿Es idiomático Python usar una clase abstracta para callbacks de controladores de eventos?

Question

Estoy creando un marco de distribución de eventos que descodifica mensajes y vuelve a llamar al código de usuario. Mi C++ fondo sugiere que escribo:

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() 

continuación, el usuario marco podría escribir algo como:

class MyHandler(Handler): 
    def onFoo(self): 
     do_something() 

dispatcher = Dispatcher() 
myHandler = MyHandler() 
dispatcher.handler = myHandler 
dispatcher.run() 

Pero también se puede imaginar poniendo onFoo() y onBar() como métodos de Dispatcher y dejar que el usuario reemplazarlos con otros métodos. A continuación, el código de usuario se vería así:

def onFoo(): 
    do_something() 

dispatcher = Dispatcher() 
dispatcher.onFoo = onFoo 

yo también podría hacer una lista de Dispatcher.onFoo callables, por lo que el usuario puede adjuntar más de un manejador como en C#.

¿Cuál es la forma más pitonica de hacerlo?

Answer 1

Yo no diría que no hay nada particularmente mal de hacerlo la primera forma, especialmente si desea permitir Dispatcher objetos para personalizar de una manera organizada en tiempo de ejecución (es decir, al pasar diferentes tipos de Handler objetos a ellos), si su Handler s necesita interactuar y mantener un estado complejo.

Pero realmente no ganas nada al definir una clase base Handler de esta manera; una clase todavía podría subclase Handler sin anular ningún método, porque esta no es una clase base abstracta, es solo una clase base regular. Entonces, si hay algunos comportamientos predeterminados razonables, sugeriría que se construyan en Handler. De lo contrario, sus usuarios no obtendrán nada de Handler en absoluto; también podrían definir su propia clase Handler. Aunque si solo quieres proporcionar un marcador de posición no operativo, entonces esta configuración está bien.

En cualquier caso, yo personalmente preferiría el primer acercamiento al segundo que sugiera; No estoy seguro de que ninguno de los dos sea más "pitónico", pero el primero me parece más limpio, ya que mantiene separadas las lógicas Handler y Dispatcher. (Evita situaciones como la que se ve en threading.Thread donde sólo se puede anular de manera segura algunos métodos -. Siempre he encontrado que un poco chocante)

me siento Debo señalar, sin embargo, que si realmente quiero una clase base abstracta de buena fe, ¡deberías escribir una! A partir de 2.6, Python proporciona soporte para el abstract base classes flexible con muchas funciones agradables. Por ejemplo, puede definir un método abstracto con el decorador abstractmethod, que garantiza que debe ser anulado por la subclase; pero también puedes definir métodos regulares que no deben ser anulados. Si está buscando una versión Pythonic del lenguaje C++, esta es probablemente la mejor manera de hacerlo; no es lo mismo, por supuesto, pero se acerca más de lo que tiene ahora.