Design Patterns

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

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.

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.

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

Recomendo este :seta: http://www.submarino.com.br/produto/1/1348031/padroes+de+arquitetura+de+aplicacoes+corporativas

Martin Fowler é um dos grandes nomes em questão de Patterns

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.

acostume-se, os melhores xaropes sao os que tem gosto ruim...estes q citei sao os melhores, os melhores aki do forum aprenderam com estes livros...

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

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

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

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.

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

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.

http://br.php.net/manual/pt_BR/language.oop5.patterns.php

ou o livro use a cabeça de desing patterns, sao os 2 melhores livros...tem um topico sobre livros aki, este 2 sao os que mais aparecem no referido topico...

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

Só permite uma unica instância em toda aplicação ..

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.

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

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

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!

>
hummm....

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.

Ok, eu não duvido nada que tu me prove o contrário, mas é que eu já tive experiencia de código que eu peguei com o html gerado pelo php, e te digo que foi um desastre total, um verdadeiro "spaguetti", enfim, acho que tive entao apenas uma má experiencia que me levou a ter um conceito nada bom de html gerado pelo php. Embora eu ainda continue achando que o html deve ser feito na mão, na maioria das vezes, pode ser que em algumas ocasiões eu possa estar incorreto. E se quiser mostrar algum código ou quiser me provar o contrário, seria mt bom!

edit: A não ser que estejas se referindo a algum tipo de html dinâmico, gerado a partir de alguma situação em especial.

abraço

A menos que provem o contrário, NÃO EXISTE uma forma de não misturar PHP com HTML e MANTER a performance.

Você misturar HTML no que seria o seu Controller ao invés de misturar na View, é a mesma coisa que jogar molho de tomate em cima do sorvete.

Quando você separa sua aplicação, no mínimo nas três camadas do MVC, você ainda vai ter aquele espaguete com PHP e HTML se alternando. Mas isso vai ficar na View, separado, num único lugar.

Você até poderia criar um conjunto super complexo de classes e mais classes, todas respeitando tudo quanto é princípio da OOP e, no Controller montar o layout inteiro através de métodos aninhados em cadeia e na View dar um simples echo.

Mas você perde tanta performance que não compensa.

Concordo com o Bruno. Se alguém conseguir mostrar como não misturar PHP com HTML, por favor, afinal, estamos aqui para aprender.

Eu sinceramente não sei onde, quem e porque raios alguém, algum dia, achou que misturar HTML com PHP não é uma boa prática.

Agora, se me permitem, ainda sinceramente falando, eu acho que esse alguém estava estudando MVC, não entendeu o que leu, e saiu falando besteira, baseando-se exclusivamente na sua não compreensão de um assunto que, muito provavelmente, estudou pela metade.

:seta: PHP foi construída para ser embutida no HTML.

>
:seta: PHP foi construída para ser embutida no HTML.

Exato , mas ainda tem o oposto disso aí 'HTML ser embutido em PHP' .. não nego que tenho minhas views que emitam html .. claro .. mas as vezes isso torna o código meio 'repetido' não ?

>
Exato , mas ainda tem o oposto disso aí 'HTML ser embutido em PHP' ..

Não importa se o PHP está embutido no HTML ou se é o contrário. O fato é que a mistura faz parte.

Agora, minha marcação também é montada pelo meu PHP e garanto, não existe repetição.