Slides da oitava e última aula de Programação Orientada a Objetos no curso de Pós Graduação em Análise e Desenvolvimento Aplicados à Gestão Empresarial
Recommending refactoring operations in large software systems
Bad Smells e Design Patterns
1. 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
2. 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.
3. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refused Bequest
• Quando herdamos de uma classe, mas não
queremos fazer uso de alguns métodos
herdados.
4. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Feature Envy
• Quando um método está mais interessado
em outro objeto do que no próprio objeto
no qual ele está inserido.
5. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Intimidade Inapropriada
• Métodos que conhecem demais sobre a
implementação de outra classe
6. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
God Class ou Blob
• Classes que controlam muitos objetos do
sistema. Tendem a crescer mais do que
deveriam e “fazer tudo”
7. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Divergent Changes
• Classes não coesas, que sofrem constantes
alterações devido a terem diversas
responsabilidades
8. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Shotgun Surgery
• Classes que possuem métodos que, toda
vez que alteram, disparam mudanças em
diversos outros lugares do código
9. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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
10. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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..
11. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Design Patterns
13. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Primeiro Exemplo
14. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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;
15. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Strategy
Solução?
16. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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.
18. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Strategy
Resolve?
19. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Strategy
Resolve?
20. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Strategy
Strategy é um padrão que deve ser utilizado
quando uma classe possuir diversos
algoritmos que possam ser utilizados de
forma intercambiável.
21. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Template Method
• Algoritmo Geral na superclasse (parte
fixa);
• Passos distintos nas subclasses (parte
variável), fornecendo implementação
própria, completando lacunas.
22. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Template Method
23. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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.
24. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Template Method
25. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Template Method
26. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refatorar para Template
Method
• Funcionalidades com similaridades nos
algoritmos são implemetadas em diferentes
classes, gerando duplicação de código.
27. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refatorar para Template
Method
• Funcionalidades com similaridades nos
algoritmos são implemetadas em diferentes
classes, gerando duplicação de código.
28. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Factory Method
• Encapsular a criação de objetos através da
herança
31. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Bridge
• Um dos problemas da Herança, é quando se
precisa de uma implementação que combine o
comportamento das subclasses
32. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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.
33. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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.
34. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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.
35. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Observer
• Utiliza composição com múltiplos objetos;
• Mudanças em objetos são notificadas para outros
objetos interessados.
38. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
State
• Utilizando composição, permite a variação de
comportamento de acordo com o estado de
uma entidade do sistema
39. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
State
• Aplicação do algoritmo state para busca em
profundidade dos grafos
40. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refatorar substituindo
condicionais por
polimorfismo
41. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refatorar substituindo
condicionais por
polimorfismo
• Antes e depois
42. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refatorar substituindo
condicionais por
polimorfismo
• Antes e depois
43. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Composição Recursiva
• Criação de uma estrutura mais robusta
colocando instâncias da superclasse ou
interface nas subclasses;
44. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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
45. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Composite
• Modelagem do Composite com trechos de
vôo
46. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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.
47. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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
48. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
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”.