Universidade Federal de Pernambuco
Centro de Informática
Disciplina: Tópicos Avançados em Engenharia de Software (
IF722)Professor: Paulo Henrique Monteiro Borba (
phmb@cin.ufpe.br)Atividades 4 e 5
Refatoramento, padrões de projetos,
componentes e parametrização
Equipe:
Filipe Wanderley Lima (fwl@cin.ufpe.br);
Maria Carolina Revoredo Martiniano (mcrm2@cin.ufpe.br).
1
Controle de Versões
Versão
Data
Descrição
Autor(es)
2
Sumário
1. Atividades ...3
2. Repetição do método doPost nos servlets ...4
3. Métodos grandes ...5
4. Abstração dos repositórios com o Bridge...9
5. Validações dos campos nos controles ... 12
6. Repetição de métodos ... 13
7. Muitos servlets ... 13
8. Desorganização dos pacotes ... 16
9. Dependência da implementação dos repositórios ... 17
10. Configurações dentro do código ... 19
3
1.
Atividades
Refatorar o sistema escolhido de forma a aumentar reuso e modularidade de código: Resolver os principais problemas identificados em atividades anteriores; Usar padrões quando apropriado;
Seguir valores e princípios quando não encontrar padrão apropriado; Registrar:
o Código anterior e posterior ao refactoring;
o Refactorings utilizados e passos manuais necessários; o Padrões utilizados ou princípios seguidos.
Refatorar o sistema escolhido para resolver problemas identificados utilizando técnicas de parametrização e componentes (ou factories com dependency injection).
4
2.
Repetição do método doPost nos servlets
Antes:
Todas as classes que herdavam de HttpServlet replicavam o método doPost.
Visão polimétrica do SourceMiner. Depois:
Foi criado a classe abstrata RGMSHandler que herda de HttpServlet e implementa o método doPost que é comum a todos os servlets usados no projeto. Todas as classes de servlet passaram a
extender desta nova classe.
Nova classe abstrata criada: RGMSHandler.
5
Nesta última imagem, o retângulo verde representa a classe HttpServlet e o retângulo
marrom a classe RGMSHandler. Nota-se que agora apenas quatro classes herdam de RGMSHandler. A nova classe também será incrementada com mais operações comuns a todas as suas subclasses. Este fato será explicado mais a frente quando o problema de grande número de servlets for tratado.
3.
Métodos grandes
Caso GerarListaPublicacaoAux Antes:
Esta classe possuía o método gerarPublicacaoBibTex com 93 linhas de código. Além disso,
várias coisas comuns que poderiam ser reaproveitadas e feitas uma única vez se repetiam pelo código.
Pedaço do método gerarPublicacaoBibTex antes.
6
Depois:Após o refatoramento nós percebemos um aumento considerável no número de métodos, porém isto é insignificante comparado a melhoria em geral de toda a classe, com métodos menores e métodos auxiliares que são reusados.
Os refatoramentos Extract Method do Eclipse foi utilizado para refatorar os métodos em métodos menores e métodos auxiliares. Outro refatoramento que foi utilizado foi o Extract Constant, para extrair constantes delimitadoras do formato BiBTeX.
Método gerarPublicacaoBibTex depois do refatoramento.
Tabela de resultado.
Visão mapa de árvore LOC da classe depois. A nova classe GerarListaPublicacaoAux pode ser vista aqui.
7
Caso PublicacaoAux Antes:
Esta classe possuía o método publicacaoAux com 104 linhas de código.
Pedaço do método publicacaoAux antes.
Classe PublicacaoAux antes do refatoramento.
Depois:
Grande parte desse método foi considerado como desnecessário e removido. No final do refatoramento o método ficou com apenas 30 LOC.
8
Classe PublicacaoAux depois do refatoramento.
Caso MembroAux Antes:
Esta classe possuía o método membroAux com 106 linhas de código.
Método membroAux antes.
Classe MembroAux antes do refatoramento.
Depois:
Igualmente ao PublicacaoAux, este método foi reduzido drasticamente. Ele passou a ter apenas
9
Pedaço do método membroAux depois.
Classe MembroAux depois do refatoramento.
4.
Abstração dos repositórios com o Bridge
MembroDAO, PublicacaoDAO, NaoMembroDAO, LinhaPesquisaDAO e ProjetoPesquisaDAO
Antes:
As classes de controle estavam dependentes da implementação do repositório em banco de dados relacional através das classes DAOs. Utilizamos o padrão Bridge para separar a abstração da implementação dos repositórios.
10
As classe MembroDAO, PublicacaoDAO, NaoMembroDAO, LinhaPesquisaDAO e ProjetoPesquisaDAO antes do refatoramento.
Depois:
As classes DAO foram totalmente refatoradas. Os comandos SQL foram armazenados em constantes da classe, através do refactoring Extract Constant, melhorando a legibilidade do código. Algumas consultas também foram reformuladas em métodos que, com o uso de parâmetros, têm a mesma funcionalidade, mas agem em tabelas diferentes.
O tratamento das exceções também foi melhorado. Antes eles não eram tratados e depois passaram a ser. Além disso, os objetos PreparedStatement e ResultSet não eram devidamente
fechados após seus usos, resultando muitas vezes em desperdício de memória.
As classes DAO passaram a ser chamadas de Repositorio*BDR e passaram a herdar da nova classe abstrata RGMSRepositorio. Esta classe possui métodos em comuns com todos os repositórios como o construtor e passagem da conexão e os métodos que fecham o ResultSet e o PreparedStatement.
As classes de controle passaram a utilizar novas classes de cadastros ao invés de usar diretamente as DAOs. Estas classes de cadastro possuem uma interface de repositório para executar suas funcionalidades, abstraindo assim as suas implementações. Estas interfaces herdam de uma interface de repositório genérica que possui os métodos comuns a todos os repositórios. Já as implementações BDR implementam as interfaces de repositório e herdam do repositório abstrato.
11
Estrutura de algumas classes depois com padrão Bridge.
Classe RepositorioMembrosBDR, RepositorioPublicacoesBDR, RepositorioNaoMembrosBDR, RepositorioLinhasPesquisaBDR e RepositorioProjetosPesquisaBDR depois do
12
5.
Validações dos campos nos controles
Antes:
Todos as classes de controladores possuem um método para validar os campos dos objetos que manipulam. Este método se repetia em todas as classes.
Exemplo da classe ControleMembro.
Depois:
Inicialmente foi pensado na idéia de criar uma super classe para todos os controladores que teria os métodos para validar os campos. Porém, foi avaliado que este não seria uma boa idéia, pois obrigaria alguns controladores a terem métodos que são usados por eles.
A nossa idéia foi criar uma classe Validador no pacote util que teria os métodos de
validação dos campos. Assim cada controlador usaria somente os métodos que fossem preciso para validar seus campos.
13
6.
Repetição de métodos
Antes:
Os métodos acima se encontravam espalhados por várias classes de servlets. Para evitar esta repetição foi criado em cada classe básica um método estático que tem a mesma funcionalidade do método original.
Método preencherMembros que era replicado em vários servlets.
Exemplo de como ele era usado.
Depois:
Os métodos de preencher se tornaram métodos estáticos dentro de suas classes básicas. Assim, estes métodos estarão em apenas um único lugar, facilitando o seu reuso.
Método preencherMembros passou a ser da classe Membro.
Exemplo de como seu uso ficou depois do refatoramento.
14
Caso LinhaPesquisa e ProjetoPesquisa Antes:
Antes os servlets relacionados à LinhaPesquisa estavam divididos em quatro: BuscarLinhaPesquisaServlet, CadastrarLinhaPesquisaServlet, EditarLinhaPesquisaServlet e RemoverLinhaPesquisaServlet. Já o servlet relacionado à ProjetoPesquisa era o ProjetoPesquisaServlet.
O método doGet da classe BuscarLinhaPesquisaServlet.
Depois:
As quatro classes anteriores se juntaram em uma única de nome HandlerLinhaPesquisa. Já o
ProjetoPesquisaServlet passou a se chamar HandlerProjetoPesquisa. Estas classes
passaram a herdar da classe abstrata RGMSHandler.
A classe abstrata RGMSHandler possui métodos comuns a todos os handlers que serão implementados mais a frente. Um destes métodos, o encaminharTela, recebe o nome de um tela
por parâmetro e redireciona para ela. Este método é bastante utilizado por vários servlets na hora de redirecionar para uma página de sucesso, falha ou outra qualquer.
Além disso, a classe RGMSHandler faz uso do padrão de projeto Template. Ela implementa o método doGet, responsável por responder a requisição HTTP. O detalhe é a operação executada
por este método é feita pelo método abstrato executarOperacao. Cabe então as subclasses do
RGMSHandler implementar este método, que varia de acordo com o handler.
15
Várias coisas foram refatoradas, como por exemplo: a instanciação da Fachada que antes era feita para cada operação e agora acontece uma única vez; linhas de código replicadas foram refatoradas de modo que ocorressem uma única vez e isso fosse reaproveitado; o redirecionamento para páginas de sucesso ou falha que antes se repetia para cada operação e agora só acontece uma única vez; entre outros.
O método executarOperacao de HandlerLinhaPesquisa.
Caso Publicacao e Membro Antes:
Antes os servlets relacionados à Publicacao estavam divididos em: BibtexPublicacaoServlet, BuscarPublicacaoServlet, CadastrarPublicacao2, CadastrarPublicacaoServlet, EditarPublicacao2Servlet, EditarPublicacaoServlet, GerarListaPublicacaoServlet e GerarListaPublicacaoPDFAux. Já os servlets relacionados à Membro estavam divididos em: BuscarMembroServlet, CadastrarMembroServlet, EditarMembroServlet e DeletarMembroServlet.
Depois:
Da mesma maneira que no caso anterior, todos os servlets acima foram juntados em uma única classe chamada de HandlerPublicacao e HandlerMembro. Igualmente, estes handlers possuem as mesmas características do HandlerLinhaPesquisa e HandlerProjetoPesquisa.
A classe BibtexPublicacaoServlet foi refatorada na operação de parâmetro “bibtex”. As
classes GerarListaPublicacaoServlet e GerarListaPublicacaoPDFAux foram refatoradas
na operação de parâmetro “listarPublicacao”. A classe BuscarPublicacaoServlet for refatorada
16
As classes CadastrarPublicacaoServlet, CadastrarPublicacao2, EditarPublicacao2Servlet, EditarPublicacaoServlet são 99% idênticas entre si, variando
apenas o tipo de operação entre cadastrar e editar. Todas elas foram refatoradas nas operações de parâmetro “c” para cadastro e “e” para atualização. Tudo o que eram comuns as duas operações e antes estava repetido, agora acontece uma única vez, ao mesmo tempo que servindo para as duas.
A classe BuscarMembroServlet foi reforatorada na operação de parâmetro “p”. A classe CadastrarMembroServlet e EditarMembroServlet que também eram muitos parecidas foram
refatoradas nas operações de parâmetro “c” e “e”, reaproveitando o que há de comum entre as duas. A classe DeletarMembroServlet foi refatorada na operação de parâmetro “r”.
Depois de todo este processo, conseguimos reduzir de 12 para apenas 2 classes. Uma redução muito significante e que melhorou a qualidade do projeto.
8.
Desorganização dos pacotes
Antes:
Antes os pacotes dos projetos eram organizados de maneira que não ajudava na coesão do sistema. Todas as classes básicas estavam em um único pacote, todos as classes DAO em outro e por aí.
Depois:
Os pacotes foram reorganizados de maneira a fortalecer a coesão. A organização ficou a seguinte: controles: pacote com a Fachada e as classes de controles dos outros pacotes;
handlers: as classes responsáveis por ligar a Fachada e os JSPs;
linhaPesquisa: a classe básica e as classes de dados;
membro: as classes básicas e as classes de dados;
naomembro: a classe básica e as classes de dados;
projeto: a classe básica e as classes de dados;
publicacao: as classes básicas e as classes de dados;
17
Estrutura dos pacotes depois da reorganização.
9.
Dependência da implementação dos
repositórios
Antes:
Apesar de o padrão Bridge ter ajudado para separar a abstração do repositório da sua implementação, ainda assim essa separação não foi total, pois em algum lugar do código a instanciação da classe concreta terá que acontecer.
Exemplo da classe ControleMembro instanciando o RepositorioMembrosBDR.
Depois:
Foi utilizado o Spring para injetar a dependência entre os repositórios e sua implementação. As classes de cadastro passaram a ter o método setRepositorio, necessário para a injeção de
18
Exemplo da classe CadastroMembros.
As classes controle passaram a herdar da classe abstrata RGMSControle. Esta classe é a responsável por instanciar o objeto ApplicationContext do Spring que lê um arquivo XML e dele
consegue associar a dependência.
Exemplo do arquivo XML necessário para usar a injeção de dependência.
As classes de controle passaram a instanciar as classes de cadastro sem instanciar a implementação do repositório, como acontecia antes.
19
10.
Configurações dentro do código
Antes:
Antes, dados como os de configuração do banco, caminhos de pastas temporárias, caminho de outros arquivos de configurações estavam espalhados por dentro do código.
Depois:
Foi utilizado o padrão Singleton com uma nova classe chamada Configuracoes do pacote util.
Esta classe faz uso da classe Properties de Java para ler um arquivo de propriedades e recuperar
os valores de acordo com a chave dada.
Com isso, todos os dados de configurações foram removidos de dentro do código e foram colocados em um arquivo de propriedades, que é então acessado pela classe Configuracoes quando necessário.
11.
Comparação geral
Mapa de árvore de linhas de código Antes:
20
Depois:Percebemos que apesar do número de métodos ter aumentado significantemente, agora existem menos classes e o tamanho dos métodos estão menores e são reaproveitados.
Visão polimétrica Antes:
21
Depois:Percebemos que houve uma redução considerável no número de servlets existentes para apenas cinco. Interfaces são agora usadas desacoplar os repositórios caso eles precisem ser mudados futuramente. Notamos também o uso de herança para compartilhar características comuns entre várias classes.
22
Apesar de parecer que o pacote é possui uma alta dependência dos outros pacotes, ele apenas se comunica com um de cada. Em controles ele apenas utiliza a Fachada e nos outros pacotes somente
as classes básicas de cada um, pois ele precisa construir os objetos para executar as operações. Notamos também que não existe acoplamento aferente.
O pacote controles como era de esperar tem dependência com todos os outros pacotes, exceto o handlers, que é o único que possui acoplamento aferente.
