Skip to content

repositorio destinado aos padroes de projeto utilizando Java, contem exemplos de Codigos e Diagramas UML

Notifications You must be signed in to change notification settings

GuiAlvesdev/bertoti-padroes-projetos-java

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

37 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Padroes de Projeto em Java

Nome do Padrao anti-padrão definição do padrão problema que ele resolve Exemplo de Aplicacao
Strategy Interfaces excessivas: Criar interfaces separadas para cada variação de comportamento, mesmo que essas interfaces sejam semelhantes você criar um grande número de classes de estratégia, cada uma com apenas pequenas variações de comportamento, isso pode resultar em uma explosão de classes, tornando o código mais complexo e difícil de gerenciar envolve a definição de uma família de algoritmos, encapsulando cada um deles e tornando-os intercambiáveis. Ele permite que o cliente escolha o algoritmo a ser usado em tempo de execução, sem que o cliente precise conhecer os detalhes de implementação de cada algoritmo. Isso é alcançado por meio da criação de uma interface comum para todos os algoritmos e de várias classes concretas que implementam essa interface, cada uma representando um algoritmo específico. útil quando você tem uma classe que possui um comportamento variável que pode ser implementado de várias maneiras diferentes. Em vez de codificar todos os algoritmos diretamente na classe cliente, você pode encapsulá-los em objetos separados e permitir que o cliente selecione qual algoritmo usar dinamicamente. Isso promove o princípio do "Open/Closed" do SOLID, que sugere que as classes devem estar abertas para extensão, mas fechadas para modificação. Um exemplo de aplicacao do tipo Strateegy e um sistema de login. O sistema de login pode permitir que os usuarios facam login usando diferentes metodos como autenticacao facial senha ou biometria.
Observer Vazamento de Memória" ou "Memory Leak". Isso ocorre quando os observadores não são desregistrados corretamente do sujeito (observable) após terem terminado de observá-lo. Isso pode levar a um aumento gradual no uso de memória Define uma relação de um-para-muitos entre objetos, de modo que quando um objeto (chamado de "sujeito" ou "observável") muda de estado, todos os seus "observadores" (ou "assinantes") são notificados e atualizados automaticamente. Isso permite que objetos dependentes reajam a mudanças no estado de um objeto sem a necessidade de acoplamento rígido entre eles. Cenários em que você tem objetos que precisam reagir a mudanças em outro objeto sem criar acoplamento forte entre eles. Ele é amplamente utilizado em interfaces gráficas de usuário, sistemas de eventos, gerenciamento de notificações e muitos outros contextos. Quando você implementa o Observer Pattern, você cria uma arquitetura mais flexível e extensível, permitindo que novos observadores sejam adicionados facilmente e eliminando a necessidade de alterações no sujeito sempre que um novo comportamento for necessário. Um sistema para controlar o estoque de um supermercado. Você precisa que o sistema seja capaz de notificar os funcionários quando um produto chega ou sai do estoque.Para isso, você pode utilizar o padrão Observer. O objeto "Produto" seria o sujeito, e os funcionários seriam os observadores.
Composite Chamado de "Complexidade Excessiva". Isso ocorre quando o padrão Composite é aplicado de maneira inadequada ou quando a estrutura hierárquica de objetos se torna excessivamente complexa,Em certos cenários, você precisaria generalizar demais a interface do componente, dificultando a compreensão. O padrão composite compõe objetos em termos de uma estrutura em árvore para representar partes e hierarquias inteiras.A chave para o padrão composite é uma classe abstrata que representa tanto o objeto primitivo como os seus recipientes O aplicativo precisa manipular uma coleção hierárquica de objetos “primitivos” e “compostos”. O processamento de um objeto primitivo é tratado de uma maneira, e o processamento de um objeto composto é tratado demaneira diferente. Ter que consultar o “tipo” de cada objeto antes de tentar processá-lo não é desejável. Um exemplo seria um sistema para gerenciar um menu de restaurante. Você precisa ser capaz de criar menus de diferentes tamanhos e com diferentes tipos de itens.Para isso, você pode utilizar o padrão Composite. O objeto que seria o item do menu, seria o componente, e os menus seriam objetos compostos que podem conter outros itens de menu e assim por diante. quando for necessarios montar um novo menu e so adicionar os itens conforme o gosto.
Facade Facade Excessivamente Genérica" ou "Interface Monolítica". Esse anti-padrão ocorre quando a fachada se torna muito ampla, genérica e inchada, tentando cobrir todas as possíveis interações com o subsistema é uma classe que fornece uma interface simples para um subsistema complexo que contém muitas partes que se movem. Uma fachada pode fornecer funcionalidades limitadas em comparação com trabalhar com os subsistemas diretamente. Contudo, ela inclui apenas aquelas funcionalidades que o cliente se importa útil quando você tem um sistema complexo com muitas classes interdependentes e deseja simplificar a interação do cliente com o sistema. Ele promove a separação de preocupações e reduz o acoplamento Imagine que você está desenvolvendo um sistema de gerenciamento de uma biblioteca. O sistema deve ser capaz de realizar uma variedade de tarefas, como verificar livros, reservar livros e renovar livros.Para isso, você pode utilizar o padrão Facade. A classe Biblioteca seria a fachada, e as classes GerenciadorDeLivros, GerenciadorDeReservas e GerenciadorDeRenovações seriam os subsistemas qu utilizam essa fachada.
Singleton Singleton "Lazy Initialization" Inseguro: Implementar o Singleton usando "lazy initialization" sem considerar a segurança em um ambiente multithread pode resultar em condições de corrida. Isso ocorre quando várias threads tentam criar instâncias do Singleton simultaneamente, o que pode levar a múltiplas instâncias do Singleton padrão de projeto criacional que permite a você garantir que uma classe tenha apenas uma instância, enquanto provê um ponto de acesso global para essa instância. útil em diversas situações, como gerenciadores de recursos, caches, conexões de banco de dados, objetos de registro e muito mais, onde é importante garantir que haja apenas uma instância em todo o sistema. Um exemplo de aplicação Java Singleton é o uso de uma instância única de uma conexão com um banco de dados. Isso pode ser feito para evitar a criação de várias conexões com o banco de dados, o que pode levar a problemas de desempenho e consumo de recursos.
MVC Modelo Sobrecarregado (Bloated Model): O Modelo torna-se excessivamente complexo, assumindo muitas responsabilidades, incluindo lógica de apresentação, dificultando a manutenção e teste.Controlador Sobrecarregado (Overburdened Controller): O Controlador torna-se muito complexo, assumindo muitas tarefas, tornando-o difícil de entender e manter.Visão Inteligente (Smart View): A camada de Visão contém uma quantidade significativa de lógica de aplicativo, comprometendo a separação adequada de preocupações.Model-View Híbrido: A separação entre o Modelo e a Visão não é clara, resultando na interação direta entre elementos do Modelo e da Visão.Controlador Fino (Anemic Controller): O Controlador tem pouca responsabilidade, agindo principalmente como um intermediário direto entre a Visão e o Modelo, levando à falta de abstração e reutilização do código.Dependência Direta entre Modelo e Visão: O Modelo e a Visão se comunicam diretamente, em vez de passar por um Controlador, resultando em um acoplamento indesejado entre eles. O MVC e padrão de projeto composto, utilizando os designs patterns Observer, Composite e Strategy.Modelo de negocio - Observer O Model implementa o padrao observer para atualizar objetos interessados na ocorrencia de mudanca de seu estado O padrao Observer mantem o Model completamente independente de Controller e View Esse padrao permite usar diferentes Views com um mesmo Model, inclusive simultaneamente View/Controller - Strategy A View é configurado com um Strategy enquanto o Controller prove a estrategia A View é responsavel pelos aspectos visuais da aplicação delegando ao Controller decisoes sobre o comportamento View e Model são desacoplados atraves do Controller View - Composite Uma GUI ou Interface gráfica do utilizador consiste de conjuntos aninhados de janelas, botoes toda parte visual disponivel ao usuario, o componente da GUI é um Composite Quando a View é instada a se atualizar pelo Controller, a propagação da atualização é facilitada pelo padrão Composite Em resumo, o padrão MVC ajuda a resolver problemas de organização, manutenção, escalabilidade e testabilidade em aplicativos, tornando o desenvolvimento de software mais eficiente e robusto. Um exemplo de aplicação Java MVC é um sistema de gerenciamento de tarefas. Nesse sistema, a view seria responsável pela apresentação dos dados para o usuário, a model seria responsável por armazenar os dados e a controller seria responsável por intermediar a comunicação entre a view e a model.

About

repositorio destinado aos padroes de projeto utilizando Java, contem exemplos de Codigos e Diagramas UML

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages