Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Estou com o seguinte problema, criei uma classe chamada robo, quando acesso com ajax pela primeira vez o arquivo com a classe, instancio ela, faco operacoes etc em um segundo acesso a instancia do robo nao existe mais e todas as configuracoes sao perdidas, ele fica zerado novamente.
Alguem sabe como resolvo isso?
'e um teste de um robozinho, e uma das obrigações usar na forma aplicação stateless, eu pensei que dessa forma seria stateless , apenas o sistema rodando com os dados do fluxo, nao imaginei que a cada requisição ela se perde, alguma dica de como resolver isso de forma rapida, pensei guardar o robo em uma sessao.
Alguma dica link, sobre aplicação stateless
Se você guardar o estado em sessão, a aplicação deixa de ser stateless.
Para você implementar algo stateless, você precisa fazer o client enviar todas as informações necessárias para a aplicação e a aplicação, por sua vez, retornar todos os dados necessários para que o client possa compreender. Todas as requisições e todas as respostas precisam ser completas e independentes.
nao da o sis consiste em enviar monte de comandos para o robozinho, andar andar procurar petroleo, encontrou extrair, andar, andar.
Vou usar sessao se nao nao resolvo.
Projeto
Instruções
Desenvolva e teste o software abaixo em qualquer linguagem de sua preferência, utilizando as técnicas que julgar interessantes para resolver o problema. Não é uma necessidade trabalhar com persistência de dados (na verdade, não é recomendável), todo o software pode ser considerado stateless com seu ciclo de vida se iniciando no input do padrão de buscas e terminando na conclusão final de sucesso da missão.
Escopo
Você está desenvolvendo uma aplicação para controlar remotamente um robô prospector de petróleo. O robô funciona da seguinte maneira:
Em um dado momento, o robô se encontra em 1 de 4 estados possíveis:
o Pronto: O robô pode receber uma nova tarefa e realiza-la imediatamente.
o Ocupado: O robô se encontra executando uma determinada tarefa e não pode receber novas tarefas.
o Recuperando: O robô não está executando nenhuma tarefa, mas já pode receber a próxima tarefa que irá executar após o período de recuperação.
o Cheio: O compartimento de petróleo do robô está cheio e o mesmo não está mais apto para serviço. Isto ocorre após 5 extrações bem sucedidas de petróleo.
O robô pode receber diversas tarefas, em especial para este teste, as seguintes tarefas são necessárias:
o (A)ndar: O robô anda por 15 segundos para uma localidade não explorada.
o (P)rocurar: O robô procura petróleo por 25 segundos no local atual. A chance de encontrar petróleo é de 50% após os 25 segundos.
o Extrair: O robô extrai petróleo da área atual por 30 segundos. Para efeito deste exemplo, uma extração sempre é bem sucedida pois só deve ser ordenada após um sucesso em uma ação de “procurar”.
Por limitações de projeto, o robô não é uma entidade inteligente capaz de tomar decisões por si só e, todas estas devem vir de um ou mais centros de comando. O software do centro de comando pode receber como input um padrão de buscas para enviar para o robô executar. Exemplo:
o A A P P A A A P O software enviará para o robô as ordens de “andar”, “andar”, “procurar”, “procurar”, “andar”, “andar”, “andar” e “procurar”
O software do centro de comando deve ordenar que o robô realize extração de petróleo sempre que uma operação de buscar o encontrar.
A missão do robô deve ser considerada um sucesso se, após executar o script de buscas, o mesmo estiver em um estado “Cheio”.
Okay; você está diante de uma FSM - Finite State Machine, ou máquina de estados finita, ou autômato finito. É trabalho de faculdade?
vaga de emprego.
Entao podemos dar o problema como encerrado, nao foi erro meu e sim questao arquitetural.
Obrigado.
Foi e não foi erro seu, @hyper_pixel; veja:
>
12 minutos atrás, hyper_pixel disse:
Desenvolva e teste o software abaixo em qualquer linguagem de sua preferência, utilizando as técnicas que julgar interessantes para resolver o problema.
A descrição do problema deixa claro que você pode utilizar qualquer linguagem e quaisquer técnicas que julgar apropriado. A linguagem PHP é adequada para resolver o problema; o paradigma orientação a objetos é adequado para resolver o problema; o erro está na escolha da web para resolver o problema. Não que não seja possível fazê-lo via web, mas quando você fez essa escolha, você se deparou com a questão da destruição das instâncias no instante da resposta do servidor.
Se quer trabalhar com PHP e com orientação a objetos, primeiro compreenda que você está desenvolvendo uma FSM; compreendido isso, crie um mapa de estados, definindo o estado inicial, a transição para cada estado válido e cada ação de cada um desses estados. Isso pode ser feito com um Diagrama de Estado. Feito isso, você terá uma visão do robô para implementá-lo.
A primeira coisa que você precisa compreender é que em tecnologias server side, todo o estado de todas as instâncias é criado tão logo a aplicação receba uma requisição HTTP e destruído tão logo sua aplicação retorne a resposta. Esse é o comportamento esperado.
Compreendido isso, ou você propaga o estado, criando uma aplicação stateless - recomendável, mas bem complexo do ponto de vista de arquitetura -, ou você serializa seus objetos, salvando-os numa base ou em disco, memória, sessão, etc.