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

Resolve?

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

• 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.

Template Method

Refatorar para TemplateMethod

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

Refatorar para TemplateMethod

• 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 methodse hook classes.

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 methodse hook classes.

Observer

• Utiliza composição com múltiplos objetos;

• Mudanças em objetos são notificadas para outros objetos interessados.

Observer

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

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

Refatorar substituindo condicionais por

polimorfismo

• Antes e depois

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

Technology

smells like teens

trend teen smells like spirit

implemention patterns

eifs stencil patterns - brick wall stencils patterns

bad smells no código

bad smells (mal cheiros) em bancos de dados

patterns 233

test automation patternsにおけるdesign patterns

improving design smell detection for adoption in...

patterns (and anti-patterns) for developing machine learning...

[agile brazil2014] bad smells em bancos de dados

knitting patterns

“bad smells” en código

bad smells em uml

code smells código que huele mal…. agenda introducción...

refactoring conversation smells

design smells

on the evaluation of code smells and detection tools

database smells

documenting code - patterns and anti-patterns - nlpw 2016