Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Guilherme_90

Design Patterns

Recommended Posts

Boa tarde pessoal. Bom, estou com uma grande dúvida sobre Design Peterns (padrões de projeto) usando o PHP.
Me tirem algumas dúvidas como:

Por que usar?

Quando usar? (se puder, mostre um problema que a solução seria usar um padrão, no caso de um sistema qualquer)

Isso realmente faz parte e é importantíssimo na Orientação a Objetos?

Quem está estudando OO (como eu), necessariamente precisa saber deste assunto?


Desculpem tantas perguntas, mas realmente estou precisando de ajuda. Se puderem, mostre um exemplo real de um sistema básico que precisaria usar um padrão de projeto.
Até mais.

Compartilhar este post


Link para o post
Compartilhar em outros sites

o joao batista neto pode dizer bem, mas eu vou dar meus pitacos

 

Por que usar?

simples, eh um padrao , onde qualquer um que conheca saiba utiliza-lo, imagina que você pegou um projeto de outra pessoa, que codificou de uma maneira totalmente diferente da sua, você vai conseguir dar manutencao? eu nao conseguiria, os padores de projeto vem resolver determinados problemas, assim como diminuir tempo de resolucao destes problemas...

Quando usar? (se puder, mostre um problema que a solução seria usar um padrão, no caso de um sistema qualquer)

 

isso varia muito, cada padrao de peojeto tem um contexto, resolve um determinado problema, sao a cerca de 23 padores de projeto, cada um resolvendo um determinado problema

ex. roubo de conexao de dados, varios programdores faem um unico arquivo de conexao ao bancode dados, e saem dando include, o q gera milhares de conexoes ao banco, dando chance de alguem roubar uma dessa conexoes e usar o seu banco, você usando o padrao singleton você evita, e tem a certeza q so havera uma conexao ativa ao banco...

 

Isso realmente faz parte e é importantíssimo na Orientação a Objetos?

 

sim, faz toda a diferenca

 

Quem está estudando OO (como eu), necessariamente precisa saber deste assunto?

 

sim...digamos q os padroes de projeto fazem a OO chegarem ao estado da arte...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Por que usar?

se você tá perguntando isso, então você não tem a menor idéia doq é um padrão.

http://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software

 

 

Quando usar?

Padrões de Projeto, resolvem problemas. Use qndo você tiver um problema. Somente isso.

você não toma remédio se não tá doente.

 

 

Isso realmente faz parte e é importantíssimo na Orientação a Objetos?

sim. Porém primeiro aprenda o básico.

 

 

Quem está estudando OO (como eu), necessariamente precisa saber deste assunto?

a resposta anterior responde essa pergunta.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Muito obrigado a todos que responderam. Estou aprendendo o básico sim, tenho algumas classes, e estou desenvolvendo um sistema, "tentando" aplicar o conceito, porém é obvio que não é tão simples e fácil!

 

Aguardo respostas de outros programadores para melhorar o tópico.

Compartilhar este post


Link para o post
Compartilhar em outros sites

existe um livro sobre padores de projeto, dois alias, um eh do pablo dalloglio php com orientacao a objetos com desing patters, e outro eh da serie use a caceça - desing pattersn, tem versao em portugues, vao t ajudar muito...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Igor.php

 

Boa idéia. Eu tenho o livro em PDF desse Pablo, mas porém não gostei muito. E os livros da série Use a Cabeça, eu detesto.

Obrigado pela idéia, vou dar uma pesquisada em outros livros.

Compartilhar este post


Link para o post
Compartilhar em outros sites

estes q citei sao os melhores

 

Tem certeza ? você leu 'todo' livro do Pablo ? é um dos piores livros que já li .. afinal, ele tem alguns erros em conceitos de patterns, basta você coletar informações .. você vai ver alguns deles .. não vou definir quais são pois não me recordo dos nomes ..

 

Mas um que eu lembro é o exemplo do DataMapper ..

Compartilhar este post


Link para o post
Compartilhar em outros sites

Não sei quem são "os melhores do fórum", mas eu tb não gostei do livro do Pablo.

 

Cara.. é muita enrolação, e depois usa algo que eu não curto: php gerador de html.

Para padrões, o melhor livro que li, é este:

 

http://www.submarino.com.br/produto/1/21504505

Compartilhar este post


Link para o post
Compartilhar em outros sites

o "php gerador de html" segue a linha do php-gtk, e nao eh enrolacao, eh didatica , os melhores eu kiz dizer, hinom, joao batista neto, beraldo, marcio leandro (q ta sumido, pq sera?)....

Compartilhar este post


Link para o post
Compartilhar em outros sites

Concordo. Eu começei a ler e desisti, é MUITO estranho o método de desenvolvimento daquele livro, na boa.

Ainda bem que eu não comprei, de última hora de tanto procurar eu consegui, se tivesse comprado é certeza que iria me arrepender.

 

Não sei quem são "os melhores do fórum", mas eu tb não gostei do livro do Pablo.

 

Cara.. é muita enrolação, e depois usa algo que eu não curto: php gerador de html.

Para padrões, o melhor livro que li, é este:

 

http://www.submarino.com.br/produto/1/21504505

 

Vou ver se acho este livro em PDF! Valeu.

Compartilhar este post


Link para o post
Compartilhar em outros sites

bom...cada gosto eh gosto, mas conhecimento nao escolhe gosto...vai ver q este do link acima eh extremamente tecnico...e pelo jeito você nao chegara a terminar de le-lo como o outro...enfim...

Compartilhar este post


Link para o post
Compartilhar em outros sites

relamente gerador de html é o cumúlo e acaba com a estrutura de camadas e organização, além do proprio trabalho do web designer... Alguem poderia indicar algo para eu ler sobre singleton??

 

ex. roubo de conexao de dados, varios programdores faem um unico arquivo de conexao ao bancode dados, e saem dando include, o q gera milhares de conexoes ao banco, dando chance de alguem roubar uma dessa conexoes e usar o seu banco, você usando o padrao singleton você evita, e tem a certeza q so havera uma conexao ativa ao banco...

 

COmo funciona esse padrão singleton?? Tecnicamente falando.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Esse livro do Matt Zandstra que o William Bruno indicou é bom, mas você só vai entender depois de ler umas 3 ou 4 vezes.

O problema é que os exemplos que ele dá são meio 'irreais' para o nosso mundo.

Falar de um 'jogo estilo Civilization'? Me parece que foge um pouco ao nosso escopo.

No mais, a conceituação e a didática são muito boas...

 

Falta um pouco de material com exemplos mais 'úteis', mais aplicáveis à nossa realidade...

 

Respondendo suas perguntas

Por que usar?

 

Os padrões de projeto surgiram na área de arquitetura nos anos 70. Alguns dos gurus da computação acharam um jeito de portá-los para o mundo da engenharia de software.

Um padrão basicamente define um problema bem conhecido e aponta uma solução, muitas vezes elegante, uma obra-prima em linhas de código.

Sendo um padrão amplamente conhecido, maiores as chances de um programador utilizá-lo. Quando outro programador, que nunca viu aquele código antes bater o olho ele pode falar:

- Olha, legal... tá usando um Observer aqui.

 

Quando usar?

Essa é a principal questão. Quando alguma coisa é nova, tendemos a enxergá-la em vários lugares em que não existem.

Me lembro quando comecei a aprender Ajax. Tudo que eu fazia tinha Ajax no meio...

Da mesma forma, o uso de padrões onde eles não se encaixam também é uma "doença", tem até nome: Paternite.

Leva um certo tempo até você sacar onde deve ou não usar um determinado padrão.

 

Isso realmente faz parte e é importantíssimo na Orientação a Objetos?

Se você deseja se considerar um bom programador, sim, é indispensável. Entretanto, não coloque a carroça na frente dos bois.

É impossível entender Design Patterns OO sem saber MUITO de OO.

OO não é só sair distribuindo classes pelo seu projeto, na verdade, é MUITO mais que isso.

Eu com 5 anos de programação nas costas não sei dizer se sou BOM mesmo nisso.

 

Quem está estudando OO (como eu), necessariamente precisa saber deste assunto?

Como eu disse, faça disso uma sequência, aprenda primeiro OO, depois design patterns. Embora nem todos se baseiem em objetos, a maioria é exclusivamente para o "mundo" OO.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Esse livro do Matt Zandstra que o William Bruno indicou é bom, mas você só vai entender depois de ler umas 3 ou 4 vezes.

O problema é que os exemplos que ele dá são meio 'irreais' para o nosso mundo.

Falar de um 'jogo estilo Civilization'? Me parece que foge um pouco ao nosso escopo.

No mais, a conceituação e a didática são muito boas...

 

Falta um pouco de material com exemplos mais 'úteis', mais aplicáveis à nossa realidade...

Pior que é verdade. ^_^

 

O livro é mediano, nem bom nem ruim. Uma boa base para quem não sabe lhufas de Padrões, mas pegar o conceito que ele ensina e aplicá-lo num sistema REAL, sei lá, um site de uma loja, por exemplo, e usar os padrões certos naquilo que devem ser usados, é treta.

 

Da mesma forma, o uso de padrões onde eles não se encaixam também é uma "doença", tem até nome: Paternite.

Patternite :lol:

 

Essa foi boa. Eu acho que a maior das Patternites é a variante Singletonite.

 

Como é um padrão super fácil de implementar e oferece algo tão útil, os mais novatos (já que todos somos eternos novatos) acham que qualquer coisinha que rpecise ser perpetuada pela aplicação toda tem de enfiar um Singleton no meio.

 

O próprio Zend Framework sofreu um bom tempo com isso...

Compartilhar este post


Link para o post
Compartilhar em outros sites

relamente gerador de html é o cumúlo.

 

hummm....

 

e acaba com a estrutura de camadas e organização,

 

Acha mesmo?!

 

Isso sim, eu acho o cúmulo!

 

De fato, e lamento dizer, mas é um ponto de vista totalmente equivocado. Se for necessário, posto um exemplo para mostrar o tanto que você está errado.

 

...mas você só vai entender depois de ler umas 3 ou 4 vezes.

 

Esse tipo de literatura é muito diferente de um romance, você não lê 1 vez e gosta da história, você lê N vezes e, depois de já ter lido muito mesmo, passa a utilizar como guia de referência.

 

Falta um pouco de material com exemplos mais 'úteis', mais aplicáveis à nossa realidade...

 

Esse foi o grande motivador quando resolvi criar o tópico índice sobre Padrões GoF aqui no fórum, são exemplos aplicados em problemas reais, de usuários reais aqui do fórum.

 

Um padrão basicamente define um problema bem conhecido e aponta uma solução, muitas vezes elegante, uma obra-prima em linhas de código.

 

A elegância do código nem é importante, justamente pelo fato do código não ser importante. Mas um padrão é isso mesmo, a definição de um problema recorrente e uma solução reutilizável para ele.

 

Depois de estudar muito sobre padrões, percebi que chega-se em um ponto em que a implementação é tão irrelevante, que seu código pode ser feio, desde que a arquitetura seja bem feita.

 

Quando a aplicação for mantida, ela será baseado no comportamento das coisas. Objetos não conhecerão as classes de outros objetos porque as dependências serão injetadas, sua GUI não será afetada por mudanças em lógica porque a responsabilidade delas é bem definida e você não precisará editar código existente porque o código, depois de entregue, simplesmente não deve ser editado.

 

Uma boa solução é aquela que o responsável pela manutenção não precisa sequer ler o código para saber do que se trata. Se precisarmos ler o código de um método, então esse método não foi bem escrito e, após lê-lo, certamente programaremos para uma implementação específica em vez de programar para uma abstração.

 

Abstração é justamente isso, saber que algo faz alguma coisa, mas sem precisarmos saber como é feito.

 

Sendo um padrão amplamente conhecido, maiores as chances de um programador utilizá-lo. Quando outro programador, que nunca viu aquele código antes bater o olho ele pode falar:

- Olha, legal... tá usando um Observer aqui.

 

É por isso que, na definição de um padrão, o nome é tão importante. De fato, a própria definição de um padrão segue também um padrão:

 

Intenção:
É a primeira coisa que temos na definição de um padrão: O que devo estar querendo para utilizar esse padrão? A intenção de um padrão é como a indicação na bula de um remédio, o que ele faz, quais os problemas que ele resolve?

 

Outros nomes:
Muitas vezes um padrão é conhecido por mais de um nome, é importante conhecê-los também pois um desenvolvedor pode usar um nome diferente.

 

Motivação:
Talvez aqui seja onde a maioria dos exemplos que encontramos tanto pecam, definir um caso de uso que ilustre o problema e como os participantes se relacionam para resolver o problema ajuda a entender o padrão. Quando o caso de uso é ruim, a compreensão é ruim também

 

Aplicabilidade:
Aqui é outro ponto onde os exemplos pecam também. Aqui é definido uma situação onde um padrão pode ser aplicado para ajudar a compreender e, principalmente, reconhecer casos de uso de um determinado padrão.

 

Estrutura:
Dizem que uma imagem diz mais do que mil palavras. Diagramas são extremamente importante porque ajudam a visualizar a comunicação entre os objetos. Eu utilizo UML, mas existem muitos outros tipos de diagramas também.

 

Participantes:
São as classes e objetos que participam da solução do problema, quais suas responsabilidades.

 

Colaborações:
Como os participantes colaboram para resolver o problema

 

Consequências:
O que acontece ao usar esse padrão? Existem efeitos colaterais? Quais os resultados obtidos?

 

Implementação:
Linguagens diferem muito umas das outras, algumas tem tipagem estática, outras tipagem dinâmica. Algumas suportam recursos que jamais serão suportados em outras linguagens. A implementação descreve os problemas, dicas, técnicas e até experiência de outros desenvolvedores que você precisará saber quando for implementar o padrão.

 

Código de exemplo:
Infelizmente os desenvolvedores PHP estão muito desamparados nesse ponto. Vejo muito código de exemplo em C++ ou Java, mas é raro ver em PHP. O tópico índice que criei foi também para ajudar a melhorar isso.

 

Usos conhecidos:
Alguma aplicação ou biblioteca que fez uso desse padrão para resolver um problema de design.

 

Padrões relacionados:
Esse seria um "veja também". Existe algum padrão intimamente relacionado com esse? Qual a principal diferença entre esse e o outro?

Se você deseja se considerar um bom programador, sim, é indispensável. Entretanto, não coloque a carroça na frente dos bois.

É impossível entender Design Patterns OO sem saber MUITO de OO.

OO não é só sair distribuindo classes pelo seu projeto, na verdade, é MUITO mais que isso.

 

Assim como é impossível entender Design Patterns sem compreender Design Principles. Esses princípios são a base de qualquer padrão.

 

Como eu disse, faça disso uma sequência, aprenda primeiro OO, depois design patterns. Embora nem todos se baseiem em objetos, a maioria é exclusivamente para o "mundo" OO.

 

Aprenda primeiro os fundamentos de OO.

Em seguida princípios de design.

Somente então, estude padrões de design.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Excelente explicação do Henrique Barcelos e João Batista Neto.

Que tal fixar este tópico? O assunto está muito bom e vai tirar dúvida de muitos!

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.