Arquitetura de Software

1. Arquitetura de Software Prof. Adailton Magalhães Lima adailton@ufpa.br 2012.4

2. Anti-padrões e Refatoração

3. Agenda • Anti-Padrões • Exemplos de Anti-Padrões • “Gambi” Design Patterns • Refatoração

4. Anti-Padrões Soluções recorrentes que possuem resultados negativos; Significa: “eu apliquei a solução errada várias vezes, portanto não repita meus erros novamente”

5. Anti-Padrões • Os anti-padrões podem ser de dois tipos: • Aqueles que descrevem uma solução ruim para um problema que resultou em uma situação ruim. • Aqueles que descrevem como evitar uma situação ruim e como proceder para, a partir dela, atingir uma boa solução.

6. Padrões e Anti-padrões Anti-Padrões Padrões Contexto & Causas Problema Passar do Tempo / Novo Contexto Solução de Anti-padrão Contexto Sintomas e Consequências Solução Solução Refatorada Benefícios Consequências Soluções relacionadas Benefícios Consequências Soluções relacionadas

8. Alguns anti-padrões Copy-paste “Reinventar a roda” Código lava(Lava Flow) Cliente Completa Serviço Fachada Transparente

9. Código Lava (Lava Flow) Contexto: código com bugs que não são tratados e acabam prejudicando todo o resto relacionado ao mesmo;

10. Código Lava (Lava Flow) "AAHHH, isso? Bem, o Marcelo e o Edson escreveram esta rotina quando o João (que saiu da empresa no mês passado) estava tentando resolver o problema das funções de entrada e saída implementadas pela Irene (que agora trabalha no departamento de vendas). Eu acho que esse código não é mais utilizado, mas não tenho certeza. O Marcelo não escreveu documentaçãoe nós não temos testes automatizados, então acho melhor não mexer nisso pois pode quebrar alguma coisa. Afinal, está funcionando do jeito que está, não está? Então é melhor não mexer."

11. Código Lava (Lava Flow) • Refatoração: • Corrigir problemas pela raiz ou o ciclo de destruição da lava não terá fim;

12. Cliente Completa Serviço • Código do cliente inclui funcionalidades do serviço • Pode incluir itens como: • Validação de dados • Verificação de segurança • Conexão com banco de dados • Etc.

13. Cliente Completa Serviço //Código JSP <%! Listerrors = null; if(value.intValue() > 5) { //valida dados errors= (List) session.getAttribute(“errors”); errors.add(“Invalidvalue”); } %>

14. Fachada Transparente Sessão altamente acoplado entre fachada e entidades internas ao serviço; Prejudica performance; Aumenta a necessidade de manutenção por pr simplesmente delegar as chamadas às entidades do serviço;

15. Fachada Transparente • Refatoração: • Antes • Depois

16. Gambi Design Patterns

17. Gambi Design Patterns Anti-Padrões conhecidos e relacionados às chamadas “Gambiarras” Sátira sobre erros comuns e reais em projetos de software

18. Mochileiro das Galáxias Também conhecido como Jornada nas Estrelas ou AcrosstheUniverse. “Um objeto que atravessa todo o sistema, do banco de dados à interface, da rede ao sistema de arquivos, sem sofrer NENHUMA transformação. “ “Quando você deleta o arquivo tudo para de compilar, da interface ao código de banco e dados, e até o Microsoft Word passa a dar problemas estranhos. “

19. Lone Wolf Também conhecido por Highlander (só pode haver um), esse é a boa e velha "classe-faz-tudo". O sistema todo está concentrado numa 'classe procedimental' que faz tudo;

20. Um array vale mais que mil variáveis A declaração de variáveis, na maior parte das linguagens de programação tende a ser uma tarefa tediosa e cansativa. É muito mais eficiente e fácil declarar um array com elementos suficientes para colocar todas as variáveis que o programador julgar necessárias.

21. Um array vale mais que mil variáveis publicstaticvoidprocessaDados(Object[] dados) { ((Produto) dados[23]).setPreco((Float) dados[64]); ((Produto) dados[23]).setMargem((Float) dados[25]); ((Produto) dados[23]).setPrecoCusto((Float) dados[82]); ((Produto) dados[23]).setPromocao((String) dados[47]); ((Venda) dados[49]).addProduto((Produto) dados[23]); dados[51] = dados[44]; } Exemplo:

22. Phoenix Exception A Phoenix Exception consiste em um sistema que nunca morre, pois assim como a Phoenix, ele sempre renasce das cinzas. Segue um exemplo da Phoenix Exception: void inserir() { try { //realiza alguma ação. } catch (Throwable e) { //Aqui a Phoenix renasce... Thread.sleep(1000); inserir(); } }

23. Refatoração

24. Refatoração Refatoração é o processo de mudança do design de uma aplicação sem modificar o seu comportamento original Uma [pequena] modificação no sistema que não altera o seu comportamento funcional, mas que melhora alguma qualidadenão-funcional.

25. Refatoração • Possíveis aspectos de qualidade não-funcionais melhorados: • simplicidade • flexibilidade • clareza • desempenho

26. Refatoração Cada refatoração é simples. Demora alguns segundos ou alguns poucos minutos para ser realizado. É uma operação sistemática e óbvia. O segredo está em ter um bom vocabulário de refatorações e saber aplicá-las criteriosa e sistematicamente

28. Exemplos de refatorações • Mudança do nome de variáveis • Mudanças nas interfaces dos objetos • Pequenas mudanças arquiteturais • Encapsular código repetido em um novo método • Generalização de métodos • raizQuadrada(floatx)⇒raiz(floatx, int n)

29. Exemplo Simples de Refatoração Mover um Método: Motivação: Um método é, ouserá, utilizadopormaisfuncionalidades de umaoutraclasse do que a queelesestádefinido. Technique: Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether. Coming up: Danger!

30. Como identificarcódigo para refatorar? Martin Fowler utiliza o termo “Codesmells” para identificar momentos de refatorar; “Codesmells” são anti-padrões aplicados em código;

31. Code Smells • Código duplicado • Ruim porque se modificar uma instancia do código duplicado e não nos outros, você pode estar criando um bug; • Método long • Métodos longos são mais difíceis de entender e verificar problemas de performance e lógica; Coming up: Code Smells

32. Code Smells • Classe grande • Classes que tentam fazer muita coisa reduzem a coesão do sistema • Lista de parâmetros longa • Difícil de entender, pode ser tornar inconsistente Coming up: Code Smells

33. Referências desciclopedia.ws/wiki/Gambi_Design_Patterns http://desciclopedia.ws/wiki/Programa%C3%A7%C3%A3o_estruturada http://desciclopedia.ws/wiki/Podr%C3%B5es_de_Projeto http://www.codinghorror.com/blog/2006/05/code-smells.html http://c2.com/cgi/wiki?CodeSmell http://martinfowler.com/bliki/CodeSmell.html http://sourcemaking.com/refactoring/bad-smells-in-code

34. Referências http://refactoring.com/catalog/index.html http://netbeans.org/kb/docs/java/editor-inspect-transform_pt_BR.html http://wiki.netbeans.org/Refactoring

35. Arquitetura de Software Prof. Adailton Magalhães Lima adailton@ufpa.br 2012.4