Padrões de Projeto - JAVA

Quais padrões?
Qual classe?
Tem código?

De criação, de estrutura e de comportamento. Todos numa única classe ao mesmo tempo. Não tenho código. Estou com este desafio de conseguir fazer. Estou quebrando cabeça, achei algo meio estranho, pq cada um padrão tem sua finalidade, daí juntar tudo numa classe só…

Na minha visão, quebraria a regra de uma classe só tem uma responsabilidade, ou seja, em uma classe somente teria muita responsabilidade e isso é um grande erro. Talvez até seja possível, mas, eu pensei aqui e fiz alguns testes fica inviável fazer, porque essa classe precisaria de outras classes para colocar os outros padrões e como relatado por você fazer tudo em uma “acho” que seria um grande problema!

Concordo plenamente com vc e estou aqui angustiada pensando um modo de fazer isto uma unica classe publica java que defina os conceitos dos padrões criacional, estrutural e comportamental.

Ola @crixoliveira,

estes padrões são apresentados no livro Padrões de projeto (GOF) de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.

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

Padrões estruturais: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy;

Padrões comportamentais: Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Method, Visitor.

Embora seja um livro antigo e não específico de Java é a base dos padrões que utilizamos hoje, feliz daqueles que leram este livro e conseguem aplicar esses padrões no dia a dia do desenvolvimento.

Mas, respondendo sua pergunta, tudo em uma única classe é muito sem sentido visto que os padrões vieram para resolver problemas que muitas vezes são de arquitetura do teu software, eles tem locais especificos para atuarem, mas se mesmo assim precisa fazer o desafio, eu penso que tem como, e seria criando uma classe que tenha as 3 definições dos padrões mas não todos os patterns apenas um de cada, então poderia fazer um builder ou uma fábrica que é um decorator e um strategy ao mesmo tempo

Isso aix que preciso, exatamente isso, não TODOS numa só classe, mas um de cada tipo numa classe, ou seja, todos um tipo, sendo um de cada, mas o díficil é implementar… Vc me entendeu perfeitamente…

Na verdade, a maior parte dos padrões exige mais de uma classe/interface para ser implementado. As exceções que me vêm à mente são os padrões Singleton, e Façade. Mesmo assim, um Façade só faz sentido se existem outros objetos com os quais ele interage. Quase todos os padrões determinam que se deve haver uma separação entre a interface e as implementações concretas das classes.

Se pensarmos em mais de uma classe, aí sim a coisa começa a fazer mais sentido. Por exemplo, os padrões Composite e Visitor são frequentemente aplicados juntos. Assim como Command e Template Method. E por aí vai…

Muito obrigada pessoal pelas dicas

Olá,

Abordando a arquitetura MVC, e Design Patterns: Observer, Composite, Strategy

Bom tem muito projeto Java, principalmente em grandes empresas, que tem todos esses padrões, e muito mais, dentro de uma única classe.

Bom, minha experiência é um pouco diferente. Eu encontrei com muito mais frequência código onde um padrão poderia ter sido bem aplicado e não foi do que código onde padrões foram aplicados sem nenhuma necessidade.
Vários padrões em uma única classe… Acho difícil de existir, na prática, pelos motivos acima. Mas com “criatividade”, tudo é possível.
Agora, classes gigantescas com um mundo de responsabilidades misturadas, isso sim, eu encontrei e ainda encontro muito. Na minha opinião, isso está associado a uma maneira procedural de pensar que encara a classe como um programa.

Obrigada!

todo software remete a estrutura de comunicação da própria empresa, portanto uma empresa grande usando OO é normal ter objetos grandes que implementam vários patterns.

Os padrões tornam as classes com funções específicas, por esse motivo, esse tipo de implementação não é alicerces de padrão de projeto.
Abraços.

Em grandes empresas isso é comum por que está cheio desse tipo de programador que segue padrões de projeto.

Por isso lá tem tanto software complexo, cheio de bugs e gambiarra que ninguém quer da manutenção.

Então é possível sim.

Você esta errado, quando isso ocorre é porque foi mal aplicado, mesmo nos dias de hoje com toda essa evolução tecnologica, desenvolvedores acreditam que conhecem design patterns mas a verdade é que não conhecem, não o suficiente para ver onde se aplica determinado padrão, padrões vieram para remover a complexidade do códido e não ao contrário.

Olá,
Precisa apurar melhor alguns conceitos, pois, erro, defeito, bug e padrões de projetos, são definições e aplicações diferentes.
Inclusive os padrões sugiram como um espécie de “protocolo”.

Grande abraço.

Não. Remover a complexidade foi a promessa do DDD. Design patterns a promessa era de criar software flexível e reutilizável.

Problema é que Java OO só é usado pra criar CRUD, mas ninguém precisa de CRUD flexível e reutilizável.

Isso contradiz a minha experiência. Seja em grandes ou pequenas empresas, encontrei com mais frequência falta de entendimento acerca de padrões de projeto do que aplicação desnecessária dos mesmos

Também não sei se podemos afirmar que empresas grandes têm software mais cheio de bugs e gambiarras do que empresas pequenas. Encontrei muito software cheio de bugs e gambiarras em grandes empresas, com certeza. Mas, sem dúvida, os piores casos de baixa qualidade de código eu encontrei em software produzido por empresas pequenas.

Programador Java não passa nem da entrevista do RH se não demonstrar conhecer design patterns e ter aplicado pelo menos meia dúzia durante a carreira.

Em algumas empresas isso pode ser verdade a maior parte do tempo, mas na minha experiência eu vi “programadores Java” em pequenas e grandes empresas que não sabiam fazer um loop ou declarando métodos fora da classe.

Sabia que eu prefiro dar manutenção em código assim, que não compila?

Melhor que dar manutenção em código cheio de design patterns.

Eu entendo. É um saco encontrar um código que poderia ser extremamente simples, mas se tornou complexo devido ao uso desnecessário de mecanismos “sofisticados”. Bom, você sempre pode jogar fora e reescrever…

Por outro lado, acho que jogar o bebê fora junto com a água do banho não é a solução. Não concordo com a atitude da comunidade de programação funcional em relação a Design Patterns. A imagem abaixo resume bem essa atitude:

Imagem colada932×554 291 KB

Para mim, isso é miopia. Eu não descarto a programação funcional, nem OO. Ambos são paradigmas úteis e pdoem ser utilizados em conjunto, quando necessário.

Se tenho que reescrever é porque o software não é flexível e reutilizável.

Você é um Troll.

Você deve descartar design patterns e focar nos requisitos da aplicação que esta desenvolvendo, seja ela OO ou funcional.

Maioria se ilude com design pattern, que serve mais pra arquiteto colocar viseira em programador, e não pra ajudar a resolver requisitos que são mais importantes para o cliente.

Olha, acho que vale a pena reavaliar isso.

Lembre-se que as pessoas que criaram o movimento ágil foram as mesmas que criaram o movimento de patterns. Kent Beck, Martin Fowler, Ward Cunningham… Esse movimento surgiu de programadores e não de “enterprise architects”.

Design patterns servem para te ajudar a resolver problemas que você tem. Se você não tem um problema para o qual se aplique um determinado padrão, então não há porque usa-lo. Usar por usar leva a designs desnecessariamente complexos. Mas se você tem um problema, não sabe como lidar com ele e um design pattern se aplica, por que não usa-lo?

Patterns não são uma receita de bolo. Você vai montar um armário e tem uma caixa com 40 ferramentas. Você não tem que usar as 40 ferramentas, somente deve usar as que são realmente necessárias para fazer o trabalho. Agora, se o armário tem um monte de parafuso Allen e você não tem a chave Allen na tua caixa de ferramentas, você dançou. Eu prefiro ter uma caixa de ferramentas variada.