Quando usar sinais e slots e quando não usar

Question

Estamos usando o Qt que oferece sinais e slots que eu acho realmente conveniente.No entanto, com grande poder vem uma grande responsabilidade e acho muito fácil abusar desse recurso.

Existem práticas recomendadas para uso de slots de sinal?Estou tendo dificuldade em encontrar algumas diretrizes gerais dessa maneira.Algumas perguntas (tenho opiniões claras, mas com as quais nem todos os membros da minha equipe concordam):

• Posso usar sinais para relatar erros?
• É correto presumir que um sinal será tratado?
• Os sinais podem ser usados ​​para iniciar ações?Por exemplo. signal displayInfoScreen() deve ser tratado por um slot que mostra uma tela de informações.

Quaisquer outras opiniões sobre quando os sinais devem/não devem ser usados ​​são muito Bem-vindo!

Answer 1

Posso usar sinais para relatar
erros?

Sim, por exemplo, veja QFtp, onde o sinal concluído carrega um status.Ele não contém o erro real, apenas a informação de que ocorreu um erro.

Tudo bem supor que um sinal será tratado?

Não.O remetente nunca pode presumir que, entretanto, seu aplicativo específico pode depender disso.Por exemplo, o QAction que representa Arquivo - Novo precisa ser tratado para que o aplicativo funcione, mas o objeto QAction não está nem aí.

Os sinais podem ser usados ​​para iniciar ações?Por exemplo.O Signal DisplayInFoscreen () deve ser tratado por um slot que mostra uma tela de informações.

Novamente, sim, por exemplo, o objeto QAction.Mas se você quiser reutilizar componentes, você deve ter cuidado para garantir que a classe real não dependa disso.

Answer 2

Sinais e slots são poderosos porque desacoplam objetos.Você não pode presumir que um sinal tenha um slot conectado, conforme respondido anteriormente.

Uma grande desvantagem do design baseado em sinal/slot é que você pode facilmente perder o controle da lógica implementada, já que uma ação de um objeto pode desencadear outras ações de qualquer outro objeto que esteja conectado a um sinal emitido.É muito mais fácil ter efeitos colaterais indesejados, chamadas recursivas, etc.

Answer 3

É correto presumir que um sinal será tratado?

Não, não é.Sinais são coisas do tipo "dispare e esqueça".Quem se conecta a um sinal e o que ele faz não deve ser preocupação do emissor.

Answer 4

Posso usar sinais para relatar erros?

Sim, mas eu geralmente tornaria isso dependente da situação.Se o erro ocorrer de forma assíncrona, então um sinal para indicar isso é definitivamente adequado.Se o erro ocorrer apenas quando o código do cliente chamar uma determinada função, o erro deverá estar na resposta dessa função, não como um sinal.No entanto, há uma grande variedade de situações intermediárias que podem ser resolvidas caso a caso.

Além disso, os mecanismos de slot de sinal podem facilitar a comunicação entre threads (o que pode muito bem ser considerado o caso assíncrono), e irei usá-los para esse propósito (com ou sem erro).

É correto presumir que um sinal será tratado?

Os sinais são (filosoficamente) projetados para indicar que algo aconteceu.Como outros indicaram, nunca é uma boa ideia presumir que um sinal será compatível com um slot, ou mesmo com apenas um outra vaga.

Os sinais podem ser usados ​​para iniciar ações?Por exemplo.sinal displayInfoScreen() deve ser tratado por um slot que mostra uma tela de informações.

Os sinais podem ser usados ​​para iniciar ações, mas provavelmente não da maneira que você está pensando.O sinal indica que foo tem acontecido.Se o código que monitora sua classe decidir que quando foo acontecer, uma caixa de diálogo deverá ser mostrada e o sinal será usado para iniciar essa ação.No entanto, geralmente não é responsabilidade da classe que emite o sinal garantir que a ação adequada ocorra, porque ela não é responsável por executar essa ação.(Se fosse, então deveria fazer parte da mesma classe e nenhum sinal seria necessário.)

Answer 5

Sinais/slots (também chamados de eventos) são uma boa maneira de remover o acoplamento entre objetos.

Por exemplo, em vez de ter visualizações que entendem como o modelo funciona e quando o modelo muda, elas “ouvem” o modelo.O modelo é responsável por dizer quando muda, o que muda.

O problema com eventos é quando você os projeta de acordo com os requisitos do cliente.Por exemplo, você não deve ter sinal displayInfoScreen porque assume algo sobre objetos que usam este sinal.Em vez disso, deveria ser infoChanged e a InfoScreenDisplayer ouve esses sinais para exibi-los na tela.Se precisar, você pode adicionar mais tarde um InfoTweeterPoster que postam as informações no Tweeter sempre que elas mudam.