Atividade IV e V

(1)

Atividade IV e V

Refatorar sistemas, utilizar e avaliar padrões de projeto e

codificação e utilizar e avaliar técnicas de componentes e

parametrização (de arquivos, funções, tipos, etc.)

André Ricardo Rolim dos Reis

Thaís Melise Lopes Pina

(2)

2

Problemas detectados nas atividades anteriores e possíveis soluções

 Classes Analisadas: DissertacaoMestrado e TeseDoutorado

As classes são idênticas, além de herdarem da mesma classe (Publicacao), possuem os mesmos atributos e métodos.

Para resolver esse problema criamos uma classe ProdutoPesquisa que possui todos os atributos e métodos de DissertacaoMestrado e TeseDoutorado. Para diferenciá-las criamos um enum TipoPesquisa e ao final as classes foram excluídas. Isso segue os princípios de simplicidade e flexibilidade do código, minimização de repetição e da taxa de mudança. Usamos os refactorings extract superclass e rename do eclipse, mas tivemos que criar e/ou ajeitar, manualmente, o enum TipoPesquisa ea chamada para a nova classe.

(3)

Universidade Federal de Pernambuco Centro de Informática

Modularidade e Reuso de Software – IF722 Atividade IV e V

(4)

(5)

5

Exemplo

 Classes Analisadas: EditarPublicacaoServlet e CadastrarPublicacaoServlet

As classes são idênticas, exceto por uma funcionalidade.

Para resolver esse problema usamos o padrão de projeto Template Method. Criamos uma superclasse PublicacaoServlet que contém a parte comum do método doGet e um método abstrato callRequestDispatcher. Nas classes EditarPublicacaoServlet e

CadastrarPublicacaoServlet implementamos o método callRequestDispatcher, mantendo o

mesmo comportamento. Usamos os refactorings extract superclass e extract method do eclipse, mas tivemos que criar e/ou ajeitar, manualmente, o método abstrato da superclasse e colocar o código comum nela.

(6)

(7)

7  Classes Analisadas: EditarPublicacao2Servlet e CadastrarPublicacao2

As classes são idênticas, exceto por uma funcionalidade.

Para resolver esse problema usamos o padrão de projeto Template Method. Criamos uma superclasse Publicacao2Servlet que contém a parte comum do método doGet e um método abstrato callFachada. Nas classes EditarPublicacao2Servlet e CadastrarPublicacao2

implementamos o método callFachada, mantendo o mesmo comportamento. Usamos os

refactorings extract superclass e extract method do eclipse, mas tivemos que criar e/ou ajeitar,

(8)

(9)

(10)

(11)

11  Classes Analisadas: MembroDAO

A classe possui três métodos de listagem idênticos, que diferem no tipo – Professor,

Pesquisador e Estudante–, mas os tipos herdam da mesma superclasse, Membro.

Para resolver esse problema parametrizamos o método, criando o listarMembros.Criamos uma enum TipoMembro para diferenciar o tipo de membro que estava fazendo a chamada àquele método quando a passamos por parâmetro. A parametrização também ajudou na diferenciação das tabelas do banco de dados. Esse método genérico nos possibilita a redução da duplicação e da taxa de mudança de código, o deixa mais simples e mais flexível. Usamos os

(12)

(13)

13 Código Depois

Exemplo – Antes

(14)

14 

Classes analisadas:

EditarLinhaPesquisaServlet e CadastrarLinhaPesquisaServlet

As classes são idênticas, pois possuem três de seus quatro métodos. A exceção a igualdade possui três linhas diferentes.

Para resolver esse problema usamos o padrão de projeto Template Method. Criamos uma superclasse CadastrarEditarLinhaPesquisaServlet que contém a parte comum do método

doGet e um método abstrato callFachada. Nas classes EditarLinhaPesquisaServlet e

CadastrarLinhaPesquisaServlet implementamos o método callFachada, mantendo o mesmo

comportamento. Usamos os refactorings extract superclass, extract method e extract local variable do eclipse, mas tivemos que criar e/ou ajeitar, manualmente, o método abstrato da superclasse e colocar o código comum nela.

(15)

(16)

(17)

(18)

18  Classes Analisadas: PublicacaoDAO

Na classe há dois métodos de códigos repetidos, um para a recuperação e o outro para o cadastramento de TeseDoutourado e DissertacaoMestrado, lembrando que ambas foram substituídas pela classe ProdutoPesquisa. Porém essa refatoração não foi suficiente para excluir a duplicação dos métodos já citados, havia dois de cada.

Os métodos de recuperação o renomeamos para getProdutoPesquisa e acrescentamos nos parâmetros um objeto da enum TipoPesquisa. Para os métodos de cadastramento, fizemos a mesma coisa, só que o renomeamos para cadastrarProdutoPesquisa.

(19)

19 Código Depois – Bloco 1

Código Antes – Bloco 2

(20)

20 Exemplo – Bloco 1 -Antes

(21)

21 Exemplo – Bloco 2 – Antes

Exemplo – Bloco 2 – Depois

 Classe analisada: GerarListaPublicacao

Essa classe antes possuía uma grande quantidade de linhas de código, o que nos

chamou atenção. Ao analisarmos, percebemos que havia uma grande repetição da

chamada do método

append de

StringBuffer, muitos eram apenas para adicionar

alguma de quebra de linha. Os três tipos de strings que eram adicionadas ao final da

StringBuffer como quebra de linha são:

",\n"

;

"\",\n" e "\"\n}".

(22)

(23)

(24)

24 Exemplo

 Classes analisadas: Todas que herdam de HTTPServlet

Após todas as análises que fizemos, percebemos que muitas classes herdavam de

HTTPServlet e que todas possuíam o método doPost implementado da mesma maneira.

Para resolver esse problema, criamos uma classe (GenericServlet) que herda de

HTTPServlet e que possui o método doPost. Tivemos que retirar, manualmente, todos os

métodos doPost das classes que herdavam de HTTPServlet e mudar a herança para

GenericServlet.

Código Antes

(25)

25 Código Depois

 Classe analisada: JCBCConnection

Para alterar as configurações de acesso ao banco de dados era necessário ter acesso ao código.

Para resolver esse problema, criamos um arquivo de propriedades sendo gerenciado pela classe PropertiesLoader. Isso também aumenta a modularidade e o reuso do código.

(26)

(27)

(28)

28  DAO

A parte DAO do projeto não está abstraindo a origem e o modo de obtenção / gravação dos dados, de modo que o restante do sistema manipule os dados de forma transparente, sem se preocupar com o que acontece por trás dos panos. Isso é preocupante, pois acarretará em grandes dificuldades em processos de migrações de fonte de dados e testes unitários. No projeto existe um DAO para cada conjunto de entidades do sistema (Membro, Publicacao, LinhaPesquisa e ProjetoPesquisa) que implementa o acesso aos dados de forma concreta e direta, utilizando JDBC.

Para resolver o problema, criaremos uma interface para cada DAO com métodos de listar, criar, remover e editar (métodos de manipulação de dados). Nosso código passa a trabalhar apenas com a interface do DAO, desconhecendo a implementação utilizada (o sistema pode ter uma implementação JDBC, Hibernate, etc. do DAO). Para abstrair e isolar o modo de criação dos objetos é possível utilizar Factory. Também é possível utilizar o container spring, por exemplo, permitindo instanciar automaticamente uma das classes que implementem a interface DAO. Dessa forma, o cliente que chama os métodos de DAO não tem conhecimento algum sobre a implementação do mesmo (sobre qual classe está sendo escolhida).

 Organização dos pacotes

(29)

(30)