Padrões de Projeto - JAVA

Pessoal,

É possível uma classe Java contemplar os três padrões (de criação, de estrutura e de comportamento) de projeto ao mesmo tempo?

Estou quebrando a cabeça.

Obrigada.

1 curtida

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

1 curtida

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.

1 curtida

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

1 curtida

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…

1 curtida

Muito obrigada pessoal pelas dicas

Olá,

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

1 curtida

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.