Organizando o ciclo do pedido - página 3

 
Andrey Khatimlianskii:

Se você tiver que sacrificar o controle de todas as ordens da TC para fazê-lo, absolutamente.

Imagine: você tem uma frota de 4 caminhões. Cada um deles transporta cargas valiosas do ponto A ao ponto B. Você precisa monitorar a rota.
O que você preferiria: ter comunicação a cada minuto - com um deles, ou a cada 2 minutos - com todos eles?

No segundo caso, o atraso será ligeiramente maior, e todos os quatro podem ter que fazer um pequeno desvio se você não conseguir encaminhá-los a tempo. Mas em geral será melhor para os negócios do que gastar um caminhão e perder os outros três.

Obrigado pela associação, mas isso não parece ser uma lógica comercial. A questão parece ser fundamental e toca em princípios muito diferentes de construção TC.

 
Andrey Khatimlianskii:

A única maneira de evitar esta situação seria utilizar ordens assíncronas.

Caso contrário, ainda haveria um loop na lista de comandos a serem executados, que é essencialmente um loop nas ordens.

Somente em uma situação de fila você ainda teria que fazer provisões para substituir uma ordem antiga não executada relativa a uma ordem por uma ordem mais nova. Caso contrário, a fila poderia transbordar e as ordens enviadas para fora da fila ficariam obsoletas.

Discorda. Uma fila com execução de comando atrasada já dá assíncronia. No loop de comando, não estamos olhando para um novo ambiente. Na verdade, só pode haver um comando na fila para modificar uma determinada ordem.
 
fxsaber:

Obrigado pela associação, mas isso não parece ser uma lógica comercial. A questão parece ser fundamental e toca em princípios de construção TC completamente diferentes.

Estou disposto a ouvir a sua associação. Sim, a questão é fundamental.


Stanislav Korotky:
Eu discordo. Uma fila com execução atrasada de comandos já dá assíncronia. Não estamos olhando para um novo ambiente no loop de comando. Na verdade, só pode haver um comando na fila para modificar uma determinada ordem.

A solicitação de um novo ambiente, em geral, leva um mínimo de tempo. A parte do leão é gasta esperando uma resposta do servidor.

Você pode delegar a execução de comandos a outra (ou mesmo várias outras) EA, mas ainda assim será uma execução seqüencial de comandos. Acho que o resultado não será diferente do ciclo construído em ordem.

 
Andrey Khatimlianskii:

Pronto para ouvir a sua associação. Sim, a questão é fundamental.

Não será, pois não é forte.


Primeiro, o TS é escrito para o testador, onde as condições comerciais são ideais. Se tudo estiver bem, então eles tentam escrever a versão ao vivo de tal forma que ela esteja o mais próxima possível do que eles vêem no testador. Quaisquer outras abordagens para escrever o TS são o acerto ou erro, não a algoritmização da idéia.

Então aqui está a questão fundamental, qual é a situação de combate mais próxima a um testador? Eu expressei minha opinião (e dei um exemplo), a sua é ouvida.

 
fxsaber:

Primeiro, o TS é escrito para o testador, onde as condições comerciais são ideais. Se tudo estiver bem, então eles tentam escrever a versão ao vivo para que no mundo real ela esteja o mais próxima possível do que eles vêem no testador. Quaisquer outras abordagens para escrever o TS são o acerto ou erro, não a algoritmização da idéia.

Então aqui está a questão fundamental, qual é a situação de combate mais próxima a um testador? Eu expressei minha opinião (e dei um exemplo), eu ouvi a sua.

Ainda não ouviu porque, em sua opinião, ao trabalhar com a primeira ordem da lista, os resultados estarão mais próximos do testador (ainda estamos discutindo um sistema com várias ordens).

 
Andrey Khatimlianskii:

Ainda não ouviu por que você acha que os resultados estarão mais próximos do testador ao trabalhar com a primeira ordem na lista (ainda discutindo um sistema de várias ordens).

E isto é quase postulado em vez de comprovado, infelizmente. Como é sua opção.

Sim, não é preciso distorcer um pouco minha abordagem, não se trata da primeira encomenda, trata-se de reiniciar todo o TS após qualquer pausa.

 
fxsaber:

E isto é quase postulado em vez de comprovado, infelizmente. Tampouco é sua opção.

Sim, não é preciso distorcer um pouco minha abordagem, não se trata da primeira encomenda, trata-se de reiniciar todo o TS após qualquer pausa.

Concordo, trabalhar apenas com a primeira encomenda só funcionará em determinadas circunstâncias.

Acho que a discussão se esgotou.

 
Andrey Khatimlianskii:

Acho que a discussão se esgotou.

Sim, obrigado. A forma como a discussão foi conduzida foi muito diferente das paralelas.

 
Andrey Khatimlianskii:

A solicitação de um novo ambiente geralmente leva um mínimo de tempo. A parte do leão é gasta esperando uma resposta do servidor.

Você pode delegar a execução de comandos a outra (ou mesmo várias outras) EA, mas ainda assim será uma execução seqüencial de comandos. Acho que o resultado não será diferente do laço embutido nos pedidos.

Não se trata de tempo, trata-se de lógica (sobre o tempo - que está em outro fio ;-) ). Sua lógica (e minha lógica, já que concordo com tudo, inclusive com a analogia automática) é fazer a análise do ambiente "de uma só vez e em uma só peça", em vez de de forma fragmentária. O processamento de quaisquer efeitos colaterais é adiado para a próxima execução, pois estes efeitos serão incorporados ao novo ambiente comercial.

Outra EA está fora de questão. Tudo pode ser feito em um só. E, é claro, o resultado será equivalente a um ciclo. Só então o código será logicamente mais compreensível e realmente provará nossa lógica.

 
Stanislav Korotky:

Outra EA está fora de questão. Tudo pode ser feito em um só. E, é claro, o resultado será equivalente a um loop. É que então o código será logicamente mais claro e realmente provará nossa lógica.

Estamos aguardando um exemplo de OOP. E eu ainda o vejo na forma de um loop. A lógica não mudará porque primeiro será para determinar o que deve ser mudado e depois para as decisões que já tomamos.