Uma vez eu tive uma discussão sobre design, relativa ao padrão de comando. Meu colega afirmou que um objeto de comando não deve retornar o status (bem-sucedido, malsucedido e por quê) depois que o método .execute () for chamado. A razão é que você não deve se preocupar se o comando for executado ou não, porque o comando não deve conter nenhum estado. No entanto, você deve verificar após a chamada se o comando tiver o efeito esperado. Outro ponto que ele argumentou foi que na Gang of Four, o padrão de comando não apresenta esse caso (de status de retorno).

Eu reivindiquei o ponto oposto. O GoF não apresenta este caso, mas um padrão pode ser modelado de acordo com suas necessidades. Se um comando não for bem-sucedido, o cliente de chamada deverá receber uma prova do status e, por fim, implantar uma reação apropriada. Forçando o cliente a verificar se a ação alcançada com sucesso era propensa a erros e produzia código duplicado. Além disso, há casos em que o comando produz um resultado (por exemplo, um comando que adiciona uma linha a uma plotagem, de alguma maneira terá o id da linha para retornar ao cliente) e fingir ter comandos sem estado significava que você precisava "fish out" o novo identificador de objeto do modelo de dados.

No final, chegamos a um compromisso ao não retornar o status, mas mantendo os ids dos objetos recém-criados no objeto de comando, e o aplicativo funcionou muito bem de qualquer maneira, mas agora estou curioso para saber sua opinião também.