Anti Padrões TALP

Prévia do material em texto

Universidade Federal do Maranhão – UFMA
Centro de Ciências Exatas e Tecnológicas – CCET
Curso de Ciência da Computação
Disciplina: Tópicos Avançados em Linguagem de Programação
Aluno: Mayckerson Alexandre Franco Santos – CP 99111-19
Trabalho referente à REPOSIÇÃO
Anti-Padrões
No estudo de padrões de projeto há o conceito de anti-padrões. De acordo com Andrew Koenig (1995), se um padrão representa a “melhor prática”, então um anti-padrão representa uma “lição aprendida”. 
Existem duas noções de anti-padrões:
Aqueles que descrevem uma solução ruim para um problema que resultou em uma situação ruim;
Aqueles que descrevem como se livrar de uma situação ruim e como proceder dessa situação para uma situação boa.
Ao contrário de padrões de projeto, anti-padrões começam com uma "solução ruim" já existente, possivelmente resultada de uma inexperiência em se resolver um tipo de problema em particular ou na aplicação de um padrão de projeto em um contexto errado. O anti-padrão amplifica essa solução ruim de modo a permitir o reconhecimento da situação problemática, seus sintomas e conseqüências. O antipadrão então apresenta uma nova solução que refatora o sistema visando maximizar os benefícios e minimizar as conseqüências.
Um exemplo de anti-padrão seria uma parte do código de implementação, não documentado, que não pode ser estendido ou modificado sem extrema dificuldade devido à sua estrutura complicada e rebuscada. A partir disso serão adicionadas soluções que irão adequar-se melhor ao problema em contexto. Por isso, anti-padrões são uma extensão natural de padrões de projeto.
Enfoca-se na crescente seleção de repetidas falhas de projetos na intenção de compreender, prevenir e recuperar-se delas. Para o desenvolvedor, anti-padrões são uma nova ferramenta que interliga os conceitos de arquitetura de software com a implementação no mundo real. Eles são usados para representar um aspecto comum, os problemas que a maioria dos desenvolvedores de software enfrentam e compartilhar o conhecimento aprendido da experiência de outros desenvolvedores.
Existem algumas causa primárias para os Antipadrões, as principais são:
Pressa: quando o deadline se aproxima, qualquer coisa que parece funcionar é aceitável;
Apatia: não resolver problemas conhecidos;
Mente estreita: não praticar soluções reconhecidas como efetivas;
Preguiça: tomar decisões pobres usando a “resposta fácil”;
Avareza: apegar-se a detalhes excessivos na modelagem;
Ignorância: não buscar compreender (e.g., migração de código);
Orgulho: síndrome do “não-foi-feito-por-nós”.
No desenvolvimento de software, não basta apontar onde está o problema, mas é preciso indicar caminhos para a solução, para isso existem técnicas básicas de refabricação de programas que incluem:
Abstração para superclasse;
Aplicável a duas ou mais classes similares.
Transformar assinaturas de métodos similares em assinaturas comuns;
Criar superclasse abstrata;
Modificar código para combinar implementações selecionadas;
Migrar métodos comuns para superclasse.
Eliminação condicional;
Estrutura e comportamento de uma classe é muito dependente de um comando condicional.
Criar novas subclasses correspondentes a cada condição;
Migrar o código de ação associado a cada condição para a nova subclasse;
Redirecionar as referências às classes para indicar a subclasse adequada.
– Pode afetar construtores, declarações de tipo e invocações a métodos sobrecarregados.
Abstração agregada.
Reorganiza relacionamentos de classes para melhorar estrutura e extensibilidade.
Possíveis formas:
– Transformar relacionamentos de herança em relacionamentos de agregação;
– Migrar classes agregadas para relacionamentos de componentes;
– Migrar relacionamentos de componentes para relacionamentos de agregação;
Citarei agora alguns tipos de Anti-padrões com suas conseqüências e possíveis soluções.
A Bolha
Esta classe é o coração de nossa arquitetura!
Forma geral: Uma classe monopoliza o processamento, outras classes encapsulam dados (tipicamente, herança de projeto procedimental (processos vs. dados)).
Sintomas e conseqüências: classes com grande número de atributos ou métodos, perdendo as vantagens da orientação a objetos e tornando difícil teste e reuso.
Solução: identificar atributos e operações relacionadas de acordo com contratos coesos, migrando essas coleções de funcionalidades para seus “lares naturais”; revisar associações.
Fluxo de Lava
Acho que não é usado, mas não tenho certeza. . . deixe por aí.
Forma geral: fragmentos de código, variáveis de classes aparentemente não relacionados com o sistema.
Sintomas e conseqüências: segmentos complexos sem documentação, blocos de código comentados sem explicação; se não removido, continua a proliferar pelo sistema e outros desenvolvedores (apressados, intimidados) vão trabalhando ao redor dos fluxos de lava, gerando um sistema impossível de se entender ou documentar. 
Solução: no desenvolvimento, ter uma arquitetura sólida (interfaces estáveis, bem definidas e documentadas) antes de gerar código; na manutenção, trabalho de detetive (descoberta de sistema).
Decomposição funcional
A rotina principal está aqui, na classe Listener.
Forma geral: Desenvolvimento baseado na decomposição funcional, fazendo classes a partir de “subrotinas”.
Sintomas e conseqüências: classes com nomes de ‘funções’, contendo um único método, e nenhum uso de princípios básicos da orientação a objetos; nenhuma esperança de reusar software.
Solução: definir modelos de análise e de projeto para tentar compreender e explicar o sistema; para classes “fora” do modelo de projeto, tentar combinar com classes existentes ou transformá-las em funções de uso geral.
Poltergeists
Eu não sei bem o que essa classe faz, mas certamente é importante.
Forma geral: Classes com ciclo de vida breve, que aparecem brevemente e depois desaparecem.
Sintomas e conseqüências: Objetos e classes temporários, com associações transientes, levando a modelos de objetos desnecessariamente complexos.
Soluções: ações associadas a poltergeists devem ser movidas para as classes que elas referenciavam, removendo as “classes fantasmas” do modelo.
Martelo Dourado
Quando a única ferramenta disponível é um martelo, todo o resto vira prego.
Forma geral: Todas as soluções de uma equipe usam um produto no qual a equipe tornou-se proficiente.
Sintomas e conseqüências: Mesmas ferramentas e produtos usadas em produtos conceitualmente diversos, com a arquitetura do sistema sendo melhor descrita pelo produto, ambiente ou ferramenta; resultado em geral podem ter baixo desempenho e escalabilidade, sendo dependentes do vendedor ou da tecnologia.
Solução: Suportar filosofia de buscar novas tecnologias; projetar e desenvolver sistemas com limites claros para a substituição de componentes individuais.
Código espaguete
Você sabia que essa linguagem suporta mais de uma função?
Forma geral: Programas ou sistemas com pouca estrutura de software.
Sintomas e conseqüências: Métodos muito orientados a processos, com o fluxo de execução ditado pela implementação de objetos; muitos métodos sem parâmetros, usando variáveis de classe (“globais”), sendo de difícil reuso.
Solução: prevenção (uso apropriado de orientação a objetos); manutenção para limpeza de código (estratégias de refabricação de programas), principalmente quando for acrescentar alguma nova funcionalidade ao código espaguete.
Programação Cut-and-Paste
Isto que é eficiência: 100000 linhas de código em duas semanas!
Forma geral: Presença de vários segmentos similares de código espalhados pelo sistema.
Sintomas e conseqüências: Os mesmos bugs reaparecendo, apesar de várias correções locais; maior tempo de revisão e inspeção de código; maior custo na manutenção do software.
Solução: Enfatizar estratégia de reuso caixa-preta no desenvolvimento ou re-estruturação do código.