Eddu Posted October 22, 2007 at 09:13 PM Report Share #142257 Posted October 22, 2007 at 09:13 PM Boas Pessoal, mais uma questão minha face á utilização dos objectos em php, que apesar de sua proliferação na versão php5, por vezes não consigo adaptar o codigo que ja tinha para passar a funcionar com objectos: Supunhamos um carrinho de compras SEM Objectos: Assim que o utilizador adiciona um produto, adicionamos na base de dados, e depois mostramos em html todos os produtos que temos na base de dados de um determinado cliente. Supunhamos um carrinho de compras COM Objectos: Em vea de adicionarmos na base de dados, adicionamos um objecto produto, dentro duma class carrinho, onde ficam armazenados todos os produtos, e consultamos os produtos quando necessário através de memória. Quando o cliente fizer logout coloca-mos os mesmos na base de dados, a questão agora é: Caso tenhamos um produto A adicionado no carrinho em ambos os cados... se esse mesmo produto for modificado pelo administrador, por exemplo o preço, no caso de sem objectos, essas alterações serão logo detectadas pelo utilizador final, no caso dos objectos, como está em memória, o produto que será mostrado, nao terá o preço correcto... Espero que tenha sido explícito, gostava de saber alternativas a estas minhas afirmações, como ter um carrinho por objectos, que tenha os produtos em memória mas assim que for feito uma alteração a um desses produtos na base de dados, as alterações sejam feita em memória também. Carlos Correia Link to comment Share on other sites More sharing options...
djthyrax Posted October 22, 2007 at 09:19 PM Report Share #142260 Posted October 22, 2007 at 09:19 PM Há casos em que não se justificam usar objectos (eu raramente os uso em PHP, mas em Python é aos pontapés), e eu não usaria, usava antes arrays (vulgos "dicionários"). 😉 Não peças ajuda por PM! A tua dúvida vai ter menos atenção do que se for postada na secção correcta do fórum! Link to comment Share on other sites More sharing options...
M6 Posted October 22, 2007 at 09:33 PM Report Share #142264 Posted October 22, 2007 at 09:33 PM Claro que é possível. Tenho um site montado em PHP com OO... As questões que colocas não têm nada a ver com OO mas sim com desenho e arquitectura do teu sistema. Essas questões colocam-se independentemente de usares, ou não, objectos. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar." Link to comment Share on other sites More sharing options...
Eddu Posted October 22, 2007 at 09:42 PM Author Report Share #142268 Posted October 22, 2007 at 09:42 PM Boas M6, ideia era se possível fazeres então uma breve descrição de como resolves o problema dos objectos serem actualizados, para que todos possamos aprender. eu tenho uma loja online montado, sem utilizar OO. gostava de aprender o mesmo com objectos. Por isso gostava de todas as dicas possíveis, neste caso a resolução deste problema. Link to comment Share on other sites More sharing options...
MX+ Posted October 22, 2007 at 10:23 PM Report Share #142284 Posted October 22, 2007 at 10:23 PM É como já foi referido. Embora POO seja uma abordagem que simplifica muito os problemas pode não ser necessária ás vezes. Neste caso a função "serialize" dos objectos daria muito jeito, pois seria fácil guardar o estado do carrinho de página-para-página (guardando o estado do objecto com sessões..). Sobre o que disseste para actualizar o preço, tens de pensar numa solução deste género: Class Carrinho -------------------- - $produtos -------------------- + adicionarProduto($idProduto, $quantidade) + actualizarProduto($idProduto, $quantidade) + actualizarAtributo($idProduto, $atributo, $valor) Class Produto ----------------- - $id - $descricao - $preco - $quantidade ----------------- + construtor($id, $quantidade) [aqui é onde podes variar.. o construtor pode receber tudo:id, desc, preco.. ou entao ir buscar á bd baseado apenas no ID) + actualizarAtributo($atributo, $valor) O carrinho é responsavel por encontrar na sua variavel interna produtos a instancia do produto X e passa-lhe o atributo a alterar. Deste modo é facil atualizar preços, serializar e manter um carrinho em OO. Isto pode ser mais bem desenhado, o esquema acima está em UML (modo texto 😛 ).. Qualquer duvida ou discuçao força 😄 Link to comment Share on other sites More sharing options...
M6 Posted October 22, 2007 at 11:19 PM Report Share #142306 Posted October 22, 2007 at 11:19 PM Boas M6, ideia era se possível fazeres então uma breve descrição de como resolves o problema dos objectos serem actualizados, para que todos possamos aprender. eu tenho uma loja online montado, sem utilizar OO. gostava de aprender o mesmo com objectos. Por isso gostava de todas as dicas possíveis, neste caso a resolução deste problema. Como o MX+ referiu, se pretendes memória persistente na BD então usar serialização seria bom. Mas mesmo sem serialização, se pretendes ler sempre de BD como o fazes actualmente, então podes continuar a fazê-lo, só que em vez de leres "variáveis soltas", construires um objecto. Mas mesmo usando OO, não tens necessidade de ter um carrinho carregado com todo o objecto que modela um produto, podes ter apenas os ids dos produtos, e só consultas os produtos quando necessitas de os listar, tipicamente aquando da finalização do processo de compra. No site que tenho as actualizações em real-time não são um problema, sendo perfeitamente aceitável que algo mude após a escolha do utilizador, mas se não fosse, poderia ser perfeitamente aceitavel efectuar a compra pelo valor que foi apresentado ao utilizador quando este seleccionou o produto (até porque não ia cair bem aumentar-lhe o preço depois de alguém decidir que o ia comprar). 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar." Link to comment Share on other sites More sharing options...
pedrotuga Posted October 22, 2007 at 11:38 PM Report Share #142314 Posted October 22, 2007 at 11:38 PM O abordagem segundo o paradigma da programação orientada a objectos ( PPOO ) so tem a ver com o desenvolvimento de uma aplicação e não com a aplicação em si. Uma aplicação de gestão de dados em que o modelo de dados é desenhado para o caso, é o exemplo típico de uma situação onde a POO não aquece nem arrefece. Se é para agrupar funções e variáveis dentro de uma classe pela razão de gostares mais de ver o código assim, ou por quereres aprender a sintaxe do PHP... bem... são razões válidas, mas aí não valeu de nada usares classes e objectos. O PPOO foi criado com o o objectivo de tornar o desenvolvimento de uma aplicação mais versatil e permitir que este siga a direcção que for preciso. Basicamente as vantagens em relação a uma abordagem não orientada a objectos são: polimorfismo e herança de classes. Este conceito é explorado ao máximo por exemplo em python pela forma como os módulos mais usados estão escritos, estão feitos para ser extendidos. O php5 tem uma implementação completa de classes e objectos que te permitem perfeitamente tirar partido das vantagens da programação orientada a objectos. Mas as caracterisicas do teu programa podem não necessitar desse poder. Link to comment Share on other sites More sharing options...
Eddu Posted October 23, 2007 at 12:57 PM Author Report Share #142382 Posted October 23, 2007 at 12:57 PM Boas pessoal, alguma das ideias acima descritas acima já tinha aplicado, ou seja: Tenho uma classe produto, e uma classe carrinho... só que actualmente passo todos os atributos que vou buscar a base de dados a primeira vez...depois faço as modificações no propio objecto, utilizando serialize e sessões. uma questão agora é (esquecendo o problema das alterações que possam ser feitas nas bases de dados): è melhor ter o objecto em memória e trabalhar com ele cada vez que é para listar por exemplo o carrinho ou ir sempre a base de dados e listar os produtos que temos na base de dados isto tendo em conta largos utilizadores no site.... é melhor subcarregar a memória ou o acesso á base de dados ?? pela minha experiencia que me foi passada, o acesso ao disco é muitas vezes superior(mais tempo) ao acesso á memoria. Mas será que 1000 utilizadores cada um com o seu carrinho e 100 produtos, não ocupará demasiada memória ? em relação á ideia de ter objectos, mas ir sempre á base de dados na mesma (tendo apenas os id's dos produtos), é uma opção a tomar...visto que pensei ainda noutra hipótese...tinhamos o nosso produto addicionado no carrinho em memoria, e entrentanto o administraor eliminou o produto? vamos comprar um produto fantasma ? - - - - - - - - - - - - - - - - - outra questão seria ainda, imaginem o seguinte cenário: O utilizador adiciona vários produtos ao carrinho (em memória).... e ele apenas quer adicionar para amanhâ comprar assim que ele fizer logout, podemos fazer a passagem desse produtos para a base de dados (encomenda por exemplo). mas se o cliente fechar a página sem fazer logout ?? será viável utilizar o destruct ? e fazer o mesmo que no logout.... Carlos Correia Link to comment Share on other sites More sharing options...
LuRsT Posted October 23, 2007 at 01:22 PM Report Share #142390 Posted October 23, 2007 at 01:22 PM Mas repara, tu em php nao podes simplesmente aramazaenar as coisas numa classe, porque ao passar duma pagina para outra perdas as informacoes todas, a nao ser qu as armazenas de alguma maneira, ou por sessoes, get ou post. php na e como no C que enquanto tas a usar o programa ele aramazena as coisas. talvez o mais giro seria guardares numa sessao do user. Mas nao é de todo a mais fiável. BotNet: The Game Tudo Sobre Formigas Link to comment Share on other sites More sharing options...
Eddu Posted October 23, 2007 at 02:10 PM Author Report Share #142408 Posted October 23, 2007 at 02:10 PM depois faço as modificações no propio objecto, utilizando serialize e sessões. Sim LuRst, eu faço isso... tem se mostrado fiável, os meus problemas por vezes estão relacionados com utilização dos propios objectos, das dificuldades que eles podem trazer face á sua implementação. eu quero ter o máximo de coisas em objectos, para crirar um género de ferramente a ser aplicada a todo e qualquer site que necessite por exemplode: sessões utilizador carrinho comprs etc etc... Link to comment Share on other sites More sharing options...
LuRsT Posted October 23, 2007 at 02:13 PM Report Share #142411 Posted October 23, 2007 at 02:13 PM Epa, desde que tenho aprendido a usar OOP eu acho que é do melhor, tens uma programacao muito mais reutilizável, amigável aos teus olhos e aos de outras pessoas para além dos benificios do OOP que o pedrotuga ja mencionou e muitos mais. Só tens de ler alguns boms tutoriais, e treinar porque não é assim tao facil de dominar a programação orientada a objectos. BotNet: The Game Tudo Sobre Formigas Link to comment Share on other sites More sharing options...
MX+ Posted October 23, 2007 at 07:01 PM Report Share #142500 Posted October 23, 2007 at 07:01 PM Mas repara, tu em php nao podes simplesmente aramazaenar as coisas numa classe, porque ao passar duma pagina para outra perdas as informacoes todas, a nao ser qu as armazenas de alguma maneira, ou por sessoes, get ou post. php na e como no C que enquanto tas a usar o programa ele aramazena as coisas. talvez o mais giro seria guardares numa sessao do user. Mas nao é de todo a mais fiável. Repara que a sereliazação + sessions faz exactamente o que tu dizes que vai faltar. Ela permite que os objectos se mantanham de página para página. O problema não será esse Link to comment Share on other sites More sharing options...
MX+ Posted October 23, 2007 at 07:04 PM Report Share #142504 Posted October 23, 2007 at 07:04 PM è melhor ter o objecto em memória e trabalhar com ele cada vez que é para listar por exemplo o carrinho ou ir sempre a base de dados e listar os produtos que temos na base de dados isto tendo em conta largos utilizadores no site.... é melhor subcarregar a memória ou o acesso á base de dados ?? pela minha experiencia que me foi passada, o acesso ao disco é muitas vezes superior(mais tempo) ao acesso á memoria. Mas será que 1000 utilizadores cada um com o seu carrinho e 100 produtos, não ocupará demasiada memória ? em relação á ideia de ter objectos, mas ir sempre á base de dados na mesma (tendo apenas os id's dos produtos), é uma opção a tomar...visto que pensei ainda noutra hipótese...tinhamos o nosso produto addicionado no carrinho em memoria, e entrentanto o administraor eliminou o produto? vamos comprar um produto fantasma ? Gosto da ideia da memória, mas lá está depende muito do trafégo do teu portal. EU gostaria de ver resultados reais. Será que conseguias usar um profile a correr em real-time e dar-nos uma analize da utilizaçao Cpu/memoria/trafego do teu portal durante uma semana? (com a implementaçao dos objectos) outra questão seria ainda, imaginem o seguinte cenário:O utilizador adiciona vários produtos ao carrinho (em memória).... e ele apenas quer adicionar para amanhâ comprar assim que ele fizer logout, podemos fazer a passagem desse produtos para a base de dados (encomenda por exemplo). mas se o cliente fechar a página sem fazer logout ?? será viável utilizar o destruct ? e fazer o mesmo que no logout.... Penso que o destructor, sendo esse o trabalho dos destructores, seria o de guardar o carrinho na base-de-dados. Ou seja a cada fecho de página (não é possivel saber se é por mudar pra outra pagina ou fechar browser) , o objecto carrinho era responsavel por fazer uma cache das compra até então. Assim o carrinho mantinha-se no logout e no fecho do browser Link to comment Share on other sites More sharing options...
Eddu Posted October 23, 2007 at 08:39 PM Author Report Share #142544 Posted October 23, 2007 at 08:39 PM Pois, realmente ter a certeza da utilização do processador, disco, memória entre as duas técnicas era mesmo muito bom, para fazermos uma análise de quando devemos usar uma ou outra técnica...poderíamos tirar conclusões interessantes... a conclusão que eu tambem tirei a cerca do destruct, é que ele vai ser chamado sempre ao fim de cada página ? não me faz muito sentido, visto que o objecto permanecerá a sessão certo? será que quando a página executa o script até ao fim, considera que o objecto já nao vai ser mais utilizado ? e limpa-o... Link to comment Share on other sites More sharing options...
MX+ Posted October 24, 2007 at 11:56 AM Report Share #142617 Posted October 24, 2007 at 11:56 AM Até faz sentido, porque aquando da serelização o objecto não termina, e pode ainda ser necessário efectuar alguma operação. Mas atenção, uma coisa que descobri é que temos de ter muito cuidado com o destructor. Eu contínuo confuso (estou a programar a minha própria framework MVC) e já testei várias situações de exit/die/fatal_error e há alguns construtores que sao chamados e outros que não são.. Penso que depende do contexto de onde instancias os objectos. Se tiver class Z e depois A -> B -> C -> exit() (onde "A -> B" representa "B instanciando em A") só a class Z merece ter o seu destructor chamado. Mas tenho de investigar melhor isto porque é fundamental. Mas supondo que corre tudo bem na execução, os destructores penso que podiam formar uma cache, que mais tarde seria lida por um cron-job e que verificava o estado dos vários carrinhos "estacionados". Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now