Opinião sobre padrões de projeto

Minha Opinião:

Padrões de Projeto são legais se utilizados e implementador por pessoas com o minimo de bom senso.

Projeto sem padroes = um mundo desorganizado
Projeto com muitos padroes impostos = um mundo inflexivel e burocratico, ou seja… uma merda de vida.

Chun apoiado…

Tive experiência profissional em ambos os casos… :shock:

Horrível!!!

DP Use com moderação!!!

Abraços
Wanderson 8)

Se vai fazer um TCC é bom que entenda que Padrões (de projeto,de arquitetura,etc…) são uma linguagem.
Como tal perguntar qual é mais relevante é como perguntar quais palavras do dicionário são mais relevantes.É complexo responder a isso.

Um critério que poderia utilizar é trabalhar em cima daqueles que existe no Java SE padrão (escolha uma versão)
Vc vai descobrir que estão todos lá e isso não é coincidencia. É porque todos são relevantes, em diferentes contextos.

Além disso existem mais padrões que hoje em dia são relevantes que não constam do catálogo GoF. É importante referir que existem vários catálogo e o GoF é apenas o mais antigo.

Por muito que o tentem convencer que é possivel criar um software tecnicamente correto sem usar padrões é muito mais eficiente fazê-lo usando padrões. A Prova é que as API padrão do java seguem os padrões. É isso que as torna universais e uteis em diferentes casos.

O sou da opinião que padrões não são aplicados, padrões acontecem, e por isso que são chamados de padrões.

Desenvolvedores nos EUA, China, Europa, Austrália e até no Brasil acabam fazendo os mesmos softwares, e implementando as mesmas soluções para os mesmos problemas encontram, repetidamente, e isso sem um desenvolvedor nunca ter ouvido falar um do outro. É algo que já acontece a décadas.

Ao catalogar os padrões, a GOF e muitos outros formalizaram a existência deles, e deram um vocabulário consistente para nomeá-los (bem, fora o VO do Fowler e o VO/TO/DTO da Sun). Acho que o mais importante dos padrões dão os nomes deles. Quando esses mesmos desenvolvedores ouvem o nome Iterator, todos vão pensar na mesma coisa, e vão conseguir conversar um com o outro.

O que mais vejo por aí é gente fascinada com esses padrões, e saem usando a torto e a direito. Acabam criando um problema para aplicar a solução deles. Quem deixa os padrões acontecerem, um tempo depois vai dizer “Olha, eu estava usando uma padrão do GOF no meu projeto, e nem sabia disso”.

Em suma, eu acho padrões bem inúteis antes que você tenha experiência o suficiente para dizer que já os usou.

Bruno Laturner:

O sou da opinião que padrões não são aplicados, padrões acontecem, e por isso que são chamados de padrões.

Desenvolvedores nos EUA, China, Europa, Austrália e até no Brasil acabam fazendo os mesmos softwares, e implementando as mesmas soluções para os mesmos problemas encontram, repetidamente, e isso sem um desenvolvedor nunca ter ouvido falar um do outro. É algo que já acontece a décadas.

Ao catalogar os padrões, a GOF e muitos outros formalizaram a existência deles, e deram um vocabulário consistente para nomeá-los (bem, fora o VO do Fowler e o VO/TO/DTO da Sun). Acho que o mais importante dos padrões dão os nomes deles. Quando esses mesmos desenvolvedores ouvem o nome Iterator, todos vão pensar na mesma coisa, e vão conseguir conversar um com o outro.

O que mais vejo por aí é gente fascinada com esses padrões, e saem usando a torto e a direito. Acabam criando um problema para aplicar a solução deles. Quem deixa os padrões acontecerem, um tempo depois vai dizer “Olha, eu estava usando uma padrão do GOF no meu projeto, e nem sabia disso”.

Em suma, eu acho padrões bem inúteis antes que você tenha experiência o suficiente para dizer que já os usou.

Acho que não entendi sua opinião. Você acha que não devemos saber da existência deles, e se acontecer de usarmos, aconteceu?
Padrões são soluções para problemas específicos. Se você está com um problema e sabe que existe um padrão que resolve ele, use esse padrão. Ignorar padrões e ficar tentando resolver o problema de algum jeito qualquer, para talvez criar uma solução que seja um padrão, não faz sentido, está tentando reinventar a roda.

Dever não é a palavra, não existe obrigação de saber nada aqui, eu advogo o livre arbítrio. É recomendado saber sobre eles, fazer uma leitura, estudar. Saber que existem é o ponto principal. Sai na frente quem sabe.

Vou bater nesse ponto novamente:

Padrões são para resolver problemas. Padrões não são soluções atrás de problemas.

Se você tem um problema específico, com o conhecimento e experiência de padrões, você tenta resolver com eles rápido. Sem o conhecimento de padrões, você resolve o problema também, e a melhor solução normalmente acaba sendo o mesmo padrão que o resolveria, e sim, demorando todo esse tempo a mais reinventando a roda.

Talvez eu tenha sido meio óbvio falando que são inúteis se você não for utilizá-los, e úteis se você for. Mas foi o que disse mesmo

O que ataco é o problema de você saber, e aplicá-los mal. Tentar solucionar um problema usando padrões sem que você saiba exatamente para que o padrão serve. Tentar encaixar um padrão de qualquer maneira, deturpando o padrão e a sistema desenvolvido. É justamente a reação contrária que o padrão visa a resolver, você gastar mais tempo tentando enfiar um padrão no meio que de fato resolver o problema.

Por isso eu falo que às vezes é bom tentar resolver as coisas por si só, e não seguir um livro de receitas. Programar envolve uma dose extrema de pensamento e criatividade, seguir instruções sem pensar te leva a ficar com os olhos tapados, como viseiras para cavalos. Agora, quando você consegue pensar e ainda seguir os padrões, aí é o melhor dos dois mundos.

Por questões de aprendizado, eu acho melhor maneira de aprender a não brincar com fogo é se queimar. A dor do erro é mais forte. Você programa melhor pela vergonha do lixo que já fez.

Obs: Importante dizer que os padrões não são código pronto, são instruções em alto nível que você as aplica da melhor maneira que puder numa linguagem específica para resolver o problema também descrito em alto nível.

Padrões de projeto são uma falsa sensação de conhecimento. A existência de padrões no código pode até parecer código bem projetado mas antes é sinal de fraqueza da linguagem de programação utilizada. Padrões são implementados no nível da linguagem e não em um carrinho de compras.

Agora eu entendi o que você quis dizer, e nesse ponto concordo totalmente.

Isso é falso. Padrões podem ser implementados ao nivel da linguagem. Não o são no caso geral.
Padrões como MVC , Produtor-Consumidor e Visitor só existem ao nivel de objetos.

sergiotaborda:

mochuara:

Padrões de projeto são uma falsa sensação de conhecimento. A existência de padrões no código pode até parecer código bem projetado mas antes é sinal de fraqueza da linguagem de programação utilizada. Padrões são implementados no nível da linguagem e não em um carrinho de compras.

Isso é falso. Padrões podem ser implementados ao nivel da linguagem. Não o são no caso geral.
Padrões como MVC , Produtor-Consumidor e Visitor só existem ao nivel de objetos.

Voce mesmo se contradisse. Padrões podem ser implementados pela linguagem e o são nas melhores linguagens.

Um exemplo de Produtor-Consumidor pode ser bem simples em Clojure, que é um Lisp para JVM:

(def producer (seque 1 (cycle (range 10))))

(doseq o (take 10 producer) 
  (println "consumer:" o) 
  (Thread/sleep 1000))

Detalhe, Clojure não é uma linguagem OO.

Até hoje não entendi muito bem essa “fraqueza” da linguagem que muitas pessoas se referem. Porque pelo que entendo, se você consegue representar aquele padrão de projeto, como a linguagem pode ser “fraca”? Claro que algumas linguagens facilitam a aplicação de alguns padrões graças aos seus recursos, deixando-os implícitos e/ou com uma leitura mais “amigável”, mas não sei se isso prova que ela é mais “forte”.

Você podia por favor explanar um pouco mais sobre isso?

Abraços

"

Bom, acredito que o uso dos padrões de projeto em si, não garante a qualidade de um sistema.

O que vejo também é que muitas vezes nós desenvolvedores quando temos que desenvolver algo, que provavelmente alguém já fez algo parecido no mesmo ou em projetos anteriores, o que poderia ser aproveitado diminuindo o tempo de planejamento de uma estrutura para solucionar o problema. Mesmo quando vamos fazer algo do zero, nunca podemos sair desenvolvendo do início. É algo meio que inconsiente também. Todas as nossas implementações possuem base em algo, seja em padrão (conhecido ou desconhecido) ou em experiência.

Eu acho que é como o amigo falou: “Padrões são para resolver problemas. Padrões não são soluções atrás de problemas.”. Claro, devemos usar com moderação, pois nem sempre é a melhor saída.

Acho interessante essa troca de experiências sobre esse assunto que parece tão óbvio, mas as vezes causa a dúvida do desenvolvedor (pelo menos comigo é dessa forma).

mochuara:

sergiotaborda:

mochuara:

Padrões de projeto são uma falsa sensação de conhecimento. A existência de padrões no código pode até parecer código bem projetado mas antes é sinal de fraqueza da linguagem de programação utilizada. Padrões são implementados no nível da linguagem e não em um carrinho de compras.

Isso é falso. Padrões podem ser implementados ao nivel da linguagem. Não o são no caso geral.
Padrões como MVC , Produtor-Consumidor e Visitor só existem ao nivel de objetos.

Voce mesmo se contradisse. Padrões podem ser implementados pela linguagem e o são nas melhores linguagens.

Um exemplo de Produtor-Consumidor pode ser bem simples em Clojure, que é um Lisp para JVM:

(def producer (seque 1 (cycle (range 10))))

(doseq o (take 10 producer) 
  (println "consumer:" o) 
  (Thread/sleep 1000))

Detalhe, Clojure não é uma linguagem OO.

Isso não é uma implementaçao da linguagem, é o uso da linguagem da mesma forma que em java vc usa a linguagem.
Implementado na linguagem seria como o object do scala. se vc declara class vc está dizendo que pode criar muitos objetos - modo normal, mas se vc declara como object (palavra chave) o scala sabe que aquilo é um singleton. Por isso que eu falei que a linguagem pode dar suporte, mas não pode dar suporte a todos os padrões.

Veja que um Connection não é um Singleton. Podem (devem até) existir várias instancias desse objecto (interface).
É errado reaproveitar a mesma conexão ao longo de muito tempo.
A solução é o uso de um pool de objetos (que é um padrão).

No máximo vc terá o uso de shared Object ( um padrão que instancia e mantém uma unica instancia partilhada para todas as chamadas mas não obriga forçar a classe a asó produzir um unico objecto - exemplo de shared object é visto em Integer.valueOf() )

Ha muita confusão sobre o que é um Singleton. Singleton são raros. Muito raros.Procure na JSE por Singletons e verá.

A confusão sofre o q é um padrão implica no mesmo que usar a palavra errada num contexto.Isso distorce a comunicação e leva a erros de design.

Os padrões não estão errados, quem erra é quem os usa mal.

LedRenan, dá uma olhada nesse site http://www.dofactory.com/Patterns/Patterns.aspx

Nele cada padrão tem um “frequency of use”, você pode usar como base pra ver quais os mais usados.

sergiotaborda:

Veja que um Connection não é um Singleton. Podem (devem até) existir várias instancias desse objecto (interface).
(…)
Ha muita confusão sobre o que é um Singleton. Singleton são raros.

Recomendo a leitura do Head First Design Patterns. Lá tem um monte de exemplos em Java. Depois de ler este é mais fácil entender o livro do GoF.

Até hoje não entendi muito bem essa “fraqueza” da linguagem que muitas pessoas se referem. Porque pelo que entendo, se você consegue representar aquele padrão de projeto, como a linguagem pode ser “fraca”? Claro que algumas linguagens facilitam a aplicação de alguns padrões graças aos seus recursos, deixando-os implícitos e/ou com uma leitura mais “amigável”, mas não sei se isso prova que ela é mais “forte”.

Você podia por favor explanar um pouco mais sobre isso?

Abraços

Pra mim, linguagem forte exige escrever pouco porque o conceito que vc precisa ja foi abstraido pela linguagem.

sergiotaborda:

Isso não é uma implementaçao da linguagem, é o uso da linguagem da mesma forma que em java vc usa a linguagem.
Implementado na linguagem seria como o object do scala. se vc declara class vc está dizendo que pode criar muitos objetos - modo normal, mas se vc declara como object (palavra chave) o scala sabe que aquilo é um singleton. Por isso que eu falei que a linguagem pode dar suporte, mas não pode dar suporte a todos os padrões.

Seria como object se fosse implementado em Scala. E seria como lisp se fosse em Clojure. Essa distinção se é implementado na linguagem ou não é irrelevante se o objetivo foi alcançado e com menos esforço.

Com certeza. Por isso sou a favor da legalização de algumas drogas.

Padrões de projeto assim como a guerra contras as drogas ambos não resolvem os problemas mais difíceis.

Comece pelos mais usados. Só de vc pesquisar quais são, vai estar entendendo melhor o motivação de cada um.

Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.

bruno_rg:

Recomendo a leitura do Head First Design Patterns. Lá tem um monte de exemplos em Java. Depois de ler este é mais fácil entender o livro do GoF.

Este livro realmente é muito bom. Li e estou lendo mais uma vez para agora fazer o TCC.
Ao mesmo tempo estou fazendo a primeira leitura do livro do GoF, na qual julgo (até o momento) uma ótima referência no assunto.

Juk:

LedRenan, dá uma olhada nesse site http://www.dofactory.com/Patterns/Patterns.aspx

Nele cada padrão tem um “frequency of use”, você pode usar como base pra ver quais os mais usados.

Vou analisar este site. Realmente é algo novo e acredito que pode ser bem útil no desenvolvimento.

bobmoe:

Comece pelos mais usados. Só de vc pesquisar quais são, vai estar entendendo melhor o motivação de cada um.

Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.

Essas dúvidas surgiram conforme o caminhar do desenvolvimento do trabalho. Acredito que hoje tenho muito mais facilidade em enxergar e aplicar um padrão do que outro. Acredito que esteja faltando ainda é experiência deles dentro de um sistema, já que o mal uso, posso comprometer a qualidade do código ou entrar em uma fria.

Agradeço as sugestões.

LedRenan:

Essas dúvidas surgiram conforme o caminhar do desenvolvimento do trabalho. Acredito que hoje tenho muito mais facilidade em enxergar e aplicar um padrão do que outro. Acredito que esteja faltando ainda é experiência deles dentro de um sistema, já que o mal uso, posso comprometer a qualidade do código ou entrar em uma fria.

Agradeço as sugestões. :)

Com certeza. Por isso sou a favor da legalização de algumas drogas.

Padrões de projeto assim como a guerra contras as drogas ambos não resolvem os problemas mais difíceis.

Design Patterns não existem para resolver os problemas mais difícies. Cada Padrão é uma solução que pode ser replicada para um problema conhecido em um contexto específico.
Se um problema tem uma solução que não pode ser replicada quando esse mesmo problema ocorrer em outra ocosição então não existe um pattern para essa solução.
O problema é que muita gente quer utilizar patterns para casos que não são aplicáveis.

O problema da abordagem de padrões não é nem seu uso excessivo (também ocorre). Mas a maneira como encaramos ela.

Idealmente, deveríamos primeiro pensar no problema, encontrar uma solução possível e, caso faça sentido, usar um pattern. Infelizmente, esse não é o caminho utilizado por numerosos desenvolvedores. Pra eles, interessa saber que: vamos usar um MVC aqui, vamos utilizar o Singleton para manter um único objeto desse, depois, usaremos um DAO, e um Façade; e finalmente a pergunta: “como vamos resolver o problema?”.

Percebe? Cada vez mais as pessoas preferem se manter presas num pacote de patterns antes de pensar na solução, pois dá-se uma impressão de um processo prescritivo, algo que, com software, não existe. Por isso é que tá cheio de gente no GUJ perguntando sobre Repositories, DAO ou MVC, enchendo o saco pra que deem a eles a receita de bolo pra usar em seus projetos, mesmo as pessoas respondendo que tudo depende.

"

Olá

Leonardo3001:

O problema da abordagem de padrões não é nem seu uso excessivo (também ocorre). Mas a maneira como encaramos ela.

Idealmente, deveríamos primeiro pensar no problema, encontrar uma solução possível e, caso faça sentido, usar um pattern. Infelizmente, esse não é o caminho utilizado por numerosos desenvolvedores. Pra eles, interessa saber que: vamos usar um MVC aqui, vamos utilizar o Singleton para manter um único objeto desse, depois, usaremos um DAO, e um Façade; e finalmente a pergunta: “como vamos resolver o problema?”.

Percebe? Cada vez mais as pessoas preferem se manter presas num pacote de patterns antes de pensar na solução, pois dá-se uma impressão de um processo prescritivo, algo que, com software, não existe. Por isso é que tá cheio de gente no GUJ perguntando sobre Repositories, DAO ou MVC, enchendo o saco pra que deem a eles a receita de bolo pra usar em seus projetos, mesmo as pessoas respondendo que tudo depende.

Resposta excelente. Como foi excelente também o que o Paulo Silveira escreveu em http://www.guj.com.br/posts/list/137942.java#742409

Este mundaréu de padrões que tentam jogar em cima de quem começa a programar é um dos males do Java atual. Já acho isto faz tempo e até tive rapidamente a oportunidade de falar isto com o Paulo na última vez que almoçamos juntos. Seria muito melhor deixar a criatividade fluir e tentar resolver o problema. Tentem. Pode até ser que reinventem a roda ou encontrem dificuldades. Mas tentem antes de que algum cara que escreve complicado sugira o uso de algo que a gente só entende depois que sofre na carne.

Como eu disse para o Paulo, o estudo dos padrões não deve preocupar o desenvolvedor que ainda não é um bom programador. Antes de estudar padrões é preciso conhecer a API do Java, ler o Effective Java e entender coisas como as vantagens de desenvolver para interfaces.

[]s
Luca

LedRenan, não consegui ver aplicabilidade para o seu TCC. Você já fez o Ante-Projeto (Projeto de Pesquisa)?

bobmoe:

Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.

Exato. Porque se o pattern fosse ruim ele seria anti-pattern. :lol:

marcosalex:

Como toda boa prática, se a pessoa não souber aplicar, o remendo fica pior. É o mesmo problema dos GPs que estudam o PMBok mas não sabem aplicar as técnicas. Ou do ITIL.

A menos que o objetivo seja passar numa entrevista eu considero estudar patterns perca de tempo, principalmente pra um júnior, com o risco de ser traumático.

Só para exemplificar com um pattern pode ser usado incorretamente.

Dois contextos diferentes: sala de uma residência e sala de reunião.
Problema: Pessoas precisam entrar e sair da sala.
Solução: Deixar um buraco para que as pessoas passem (solução ruim) ou, colocar uma porta (solução padrão).

A aplicação da porta no contexto sala de reunião resolve um problema, mas acaba gerando outro.
Para saber se uma sala está em uso as pessoas precisam bater e abrir a porta e acabam interrompendo a reunião.
Portanto os arquitetos tiveram que pensar em uma solução diferente. Daí surgiu a porta com pequena janela de vidro. Por fim essa porta virou padrão para salas de reunião.

Da mesma forma a solução de porta com a janela de vidro não é uma solução boa se aplicada na sala de uma casa.

Isto é valido para qualquer tipo de pattern inclusive patterns de OO.

bobmoe:

Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.

Vamos deixar algo muito claro: Patterns não são boas práticas.

Existem patterns e existe a boa prática de os usar. São duas coisas separadas.
A boa prática está relacionada ao aprendizado e utilização dos padrões e não aos padrões em si.

O padrão em si é uma solução comprovada e canónica para um problema recorrente.
Pegando a OO e as regras que a regem (principios vários) e dado um problema vc encontra um design tal que o
problema é solucionado com o minimo de efeitos secundários para em certo contexto de uso. Isto é um padrão.
Padrões formam uma linguagem. Existem regras para definir e falar essa linguagem (como no português),mas isso
não significa que sejam “falados” corretamente. Falar corretamente é que seria a boa prática.

Patterns não são boas práticas. São bons modelos.