• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

Eddu

Utilização de Objectos em php é Viavel ?

15 mensagens neste tópico

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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"). ;)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

É 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 :P).. Qualquer duvida ou discuçao força :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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).

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

è 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

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

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".

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora