Programação Orientada a Objetos - Pós Graduação - Aula 8 - Bad Smells & Design Patterns

Programação Orientada a Objetos
Bad Smells e Design
Patterns
Pós Graduação em Análise e Desenvolvimento de Sistemas
Aplicados à Gestão Empresarial
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
TRIÂNGULO MINEIRO – Campus Uberlândia Centro
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br

Bad Smells
• Conjunto de más práticas de design
• Popularizadas no livro “Refactoring” do
Martin Fowler;
• Existem mais de 60 bad
smells, mas por questão de
escopo, serão citados
apenas 6.

Refused Bequest
• Quando herdamos de uma classe, mas não
queremos fazer uso de alguns métodos
herdados.

Feature Envy
• Quando um método está mais interessado
em outro objeto do que no próprio objeto
no qual ele está inserido.

Intimidade Inapropriada
• Métodos que conhecem demais sobre a
implementação de outra classe

God Class ou Blob
• Classes que controlam muitos objetos do
sistema. Tendem a crescer mais do que
deveriam e “fazer tudo”

Divergent Changes
• Classes não coesas, que sofrem constantes
alterações devido a terem diversas
responsabilidades

Shotgun Surgery
• Classes que possuem métodos que, toda
vez que alteram, disparam mudanças em
diversos outros lugares do código

Design Patterns
• São uma forma de se documentar uma
solução para um problema de modelagem;
• Soluções que foram implementadas com
sucesso de forma recorrente em diversos
contextos;
• Padrões de projetos ajudam a
adquirir habilidade para modelar
Software

Design Patterns
• Padrões = Aprender soluções sem precisar
passar por vários anos alternando entre
escolhas certas e erradas.
• MVC é um padrão, mas arquitetural;
• Cada tecnologia tem seus padrões, como
padrões Java EE, padrões Android, etc..

Design Patterns

J2EE Patterns

Primeiro Exemplo

Strategy
• Código ruim + funcionando = mantém do
jeito que está;
• Problemas = precisar manter o código, por
exemplo, novas regras de negócio;
• A solução da forma que está não irá
escalar para um número grande de regras;
• O código pode crescer de forma
descontrolada e se tornar não gerenciável;
• Este código necessita de refactoring;

Strategy
Solução?

Strategy
Problemas:
1 – Explosão de subclasses;
2 – Não é possível alterar o comportamento
uma vez que a classe foi instanciada.
Soluções?
1 – Herança com granularidade diferente?
Uma subclasse para cada tipo de veículo?
Problemas? Muita duplicidade de código.

Strategy

Strategy
Resolve?

Strategy
Strategy é um padrão que deve ser utilizado
quando uma classe possuir diversos
algoritmos que possam ser utilizados de
forma intercambiável.

Template Method
• Algoritmo Geral na superclasse (parte
fixa);
• Passos distintos nas subclasses (parte
variável), fornecendo implementação
própria, completando lacunas.

Template Method

Template Method
• Hook Method = técnica para permitir a
extensão do comportamento;
• Template Method = padrão de projeto
que soluciona o problema;
• Na prática, o template Method utiliza
Hook Method em sua solução;
• O conceito de Hook Method é mais geral,
também sendo utilizado por outros
padrões.

Refatorar para Template
Method
• Funcionalidades com similaridades nos
algoritmos são implemetadas em diferentes
classes, gerando duplicação de código.

Factory Method
• Encapsular a criação de objetos através da
herança

Factory Method

Bridge
• Um dos problemas da Herança, é quando se
precisa de uma implementação que combine o
comportamento das subclasses

Bridge
• O padrão Bridge irá criar uma ponte entre as duas
hierarquias ligadas por uma relação de composição;
• No exemplo, a ponte é caracterizada pela relação de
composição entre a classe GeradorArquivo e a interface
PosProcessador.

Bridge
• Um ótimo efeito colateral nesse padrão é que
classes que foram separadas podem ser
utilizadas em outro contexto;
• Bridge utiliza ao mesmo tempo herança e
composição;
• Bridge utiliza ao mesmo tempo hook methods
e hook classes.

Observer
• Utiliza composição com múltiplos objetos;
• Mudanças em objetos são notificadas para outros
objetos interessados.

Observer

State
• Utilizando composição, permite a variação de
comportamento de acordo com o estado de
uma entidade do sistema

State
• Aplicação do algoritmo state para busca em
profundidade dos grafos

Refatorar substituindo
condicionais por
polimorfismo

Refatorar substituindo
condicionais por
polimorfismo
• Antes e depois

Composição Recursiva
• Criação de uma estrutura mais robusta
colocando instâncias da superclasse ou
interface nas subclasses;

Composite
• Possui como objetivo prover uma solução para objetos
que representam um conjunto de objetos, mas que
compartilham a mesma abstração deles;
• O padrão segue uma estrutura de árvore

Composite
• Modelagem do Composite com trechos de
vôo

Chains of Responsability
• Passos que precisam ser executados em sequência,
contudo com flexibilidade na configuração destes;
• Reutilização destes passos em outros procedimentos
• Este padrão cria uma cadeia de execução na qual cada
elemento processa as informações e em seguida delega
a execução ao próximo em sequência.

Chains of Responsability
• Arquivo com uma lista de certificados digitais
revogados, atualizando de forma periódica em um
servidor remoto, contendo a data de validade;
• Caches na memória e na base de dados

Referências
• GUERRA, Eduardo. Design Patterns com Java.
Casa do Código, 2014;
• ANICHE, Maurício. Orientação a objetos e
SOLID para Ninjas. Casa do Código, 2015;
• “LARMAN, Craig – Utilizando UML e Padrões
3ª Edição. Bookman, 2007”.

Programação Orientada a Objetos - Pós Graduação - Aula 8 - Bad Smells & Design Patterns

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Programação Orientada a Objetos - Pós Graduação - Aula 8 - Bad Smells & Design Patterns

Semelhante a Programação Orientada a Objetos - Pós Graduação - Aula 8 - Bad Smells & Design Patterns (20)

Mais de Carlos Eduardo

Mais de Carlos Eduardo (7)

Último

Último (6)

Programação Orientada a Objetos - Pós Graduação - Aula 8 - Bad Smells & Design Patterns