Un desarrollador senior de mi equipo usó el estándar C-style callbacks en nuestra aplicación Qt en lugar de usar los mecanismos Qt de señal/ranura.¿Debo usar los mecanismos de ranura/señal de Qt sobre las devoluciones de llamada tradicionales?
Mi primera reacción sería la de sustituir el código y usar Qt señal/ranura en su lugar.
¿Hay alguna buenas razones para utilizar devoluciones de llamada en una aplicación/biblioteca Qt?
Gracias.
Creo que el mejor enfoque sería abrazar el marco que está utilizando y utilizar la señal/ranuras.
Dicho esto, si el código en cuestión funciona, y no es feo o problemas que causan, entonces usted puede ser mejor dejarlo solo.
Consulta del Signal/Slot documentation describe por qué el enfoque/ranura de la señal es mejor:
devoluciones de llamada tienen dos defectos fundamentales: En primer lugar , no son de tipo seguro. Nosotros nunca podemos estar seguros de que la función de procesamiento llame a la devolución de llamada con los argumentos correctos. En segundo lugar, la devolución de llamada es fuertemente acoplado a la función de procesamiento de ya que la función de transformación deberá know que devolución de llamada para llamar.
cosas sean conscientes de lo siguiente sin embargo:
En comparación con devoluciones de llamada, señales y ranuras son ligeramente más lento debido a la mayor flexibilidad que proporcionan
La velocidad probablemente no importa para la mayoría de los casos, pero puede haber algunos casos extremos de llamadas repetidas que hacen la diferencia.
+1 para ambos abrazar el marco y dejar las cosas como están. – OregonGhost
Los documentos no son realmente precisos. Las retrollamadas son de hecho seguras para tipo, a menos que use reinterpret_casts. Y con reinterpret_casts, la señal/slots tampoco son seguros. La función de procesamiento ciertamente no necesita saber a qué devolución de llamada llamar. De hecho, la implementación más común de las devoluciones de llamada no: la persona que llama pasa un puntero de función para la devolución de llamada. – MSalters
@MSalaters: Estoy de acuerdo –
Usted debe distinguir entre las devoluciones de llamada que son sincrónicas y se utiliza para devolver resultados ya sean graduales o tuplas (varios elementos, como pareja <> pero más) y las devoluciones de llamada que se encuentran bajo acoplamiento asíncrona. Las señales/ranuras generalmente deberían usarse para este último. Para el primero, puede tener sentido de cualquier manera dependiendo de si es una función principal de su aplicación (use señales/ranuras) o la interfaz de una biblioteca que no sea GUI que podría ser más portátil (use devoluciones de llamada directas para C/C++ simple código portable).
En general, no tengo reglas de diseño de programación concisas que tienden a apuntar a lo que es más limpio y menos complejidad del código/interfaz. Para el caso de devolución de tuplas, a menudo uso QMap en lugar de crear otra definición de clase o señal/ranura o método de devolución de llamada. Esto funciona bien para agrupar y pasar parámetros también, especialmente para cosas que necesitan evolucionar en diferentes partes del sistema.
cuidado con su uso plazo, el cambio de las devoluciones de llamada de tipo C a señales/ranuras suena más como una reescritura no es un refactor en este caso. Si estuviera cambiando el código en una biblioteca, podría salirse con la suya con un refactorizador, pero si se usa en toda la aplicación, lo más probable es que esté cruzando territorio de reescritura. No quiero ser tan exigente, pero la gente a menudo usa demasiado el término refactor para referirse simplemente al cambio. –
El código está ubicado dentro de una biblioteca en particular. En otros lugares estamos usando señales y ranuras ya. Gracias por tu comentario. –