Opinião sobre padrões de projeto

Assuntos Gerais
#1

E aí pessoal, blz?

Bom, este tópico vou colocar em Off, pois é um assunto que gostaria de debater sobre um TCC que estou desenvolvendo.

O tema do meu TCC é sobre “Design Patterns com desenvolvimento em Java” na qual vou procurar demonstrar exemplos de alguns padrões. Na bibliografia mais conceituada do assunto (acredito que seja) o livro do GOF na qual separa os padrões de projeto da seguinte forma:

Padrões de criação
Factory Method
Abstract Factory
Builder
Prototype
Singleton

Padrões de estrutura
Class Adapter
Objetct Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Padrões de comportamento
Interpreter
Template Method
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Como podemos ver, existem muitos padrões. Estes padrões são muito bem detalhados pelo livro “Padrões de Projeto: soluções reutilizáveis de software orientado a objetos” do GOF. Mas hoje, estou chegando a conclusão de que não vou querer abordar todos os padrões no meu TCC. Porém não estou conseguindo enxergar critérios para escolher quais padrões abordar no TCC.

Em um primeiro momento: na opinião de vocês, quais padrões vocês julgam mais importantes o desenvolvedor de sistemas conhecer a príncipio? Se for possível justificar.

Em um segundo momento, gostaria de debater, o impacto do uso de padrões de projeto no desenvolvimento de sistemas, tendo em vista a qualidade de código que eles proporcionam ou até mesmo o impacto no grupo de desenvolvimento.

Espero que eu tenha conseguido passar a ideia e me corrijam caso eu esteja errado. :slight_smile:
Obrigado.
Abraços

#2

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.

#3

Chun apoiado…

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

Horrível!!!

DP Use com moderação!!!

Abraços
Wanderson 8)

#4

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á :wink: 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.

#5

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.

#6

[quote=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.[/quote]

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.

#7

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 :slight_smile:

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.

#8

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.

#9

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

#10

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.

#11

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.
[/quote]

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:

[code](def producer (seque 1 (cycle (range 10))))

(doseq o (take 10 producer)
(println “consumer:” o)
(Thread/sleep 1000))
[/code]

Detalhe, Clojure não é uma linguagem OO.

#12

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

#13

"

#14

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

#15

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.
[/quote]

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:

[code](def producer (seque 1 (cycle (range 10))))

(doseq o (take 10 producer)
(println “consumer:” o)
(Thread/sleep 1000))
[/code]

Detalhe, Clojure não é uma linguagem OO.[/quote]

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.

#16

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.

#17

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.

#18

[quote=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.[/quote]
Concordo. E no caso de objetos de conexão a banco de dados, muitos usam singleton quando o que querem na verdade é acesso global a eles - e isso não implica necessariamente em uma única instância.

#19

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.

#20

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[/quote]

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