Artigos Canal Mais Refatoração para Padrões - Revista Engenharia de Software Magazine 37 - Parte 10
Demais posts desta série:
Refatoração para Padrões – Parte 1
Refatoração para Padrões – Parte 2
Refatoração para Padrões – Parte 3
Refatoração para Padrões – Parte 4
Refatoração para Padrões – Parte 5
Refatoração para Padrões – Parte 6
Refatoração para Padrões – Parte 7
Refatoração para Padrões – Parte 8
Refatoração para Padrões – Parte 9
Refatoração para Padrões – Parte 11
Refatoração para Padrões – Parte 12
Refatoração para Padrões – Parte 13
Artigo no estilo: Curso

De que se trata o artigo:

Aborda o tema refatoração para padrões com o objetivo de mostrar como o desenvolvedor pode usá-lo para melhorar o código-fonte de suas aplicações.


Para que serve:

Para prover conhecimento ao desenvolvedor sobre refatoração para padrões e demonstrar através de exemplos práticos a aplicação das técnicas de refatoração para padrões Unificar Interfaces com Adapter, Extrair Adapter e Substituir Linguagem Implícita por Interpreter.


Em que situação o tema é útil:

O tema se torna fundamental para desenvolvedores que já estão familiarizados com padrões de projeto e já os implementam em seus softwares e que querem saber mais sobre refatoração para padrões, conhecendo os benefícios que sua utilização traz.

Autores: Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo

As técnicas de refatoração para padrões apresentadas nos artigos anteriores são focadas em alguns cenários que evidenciam a necessidade de refatorar para um determinado padrão. Este artigo, por sua vez, não sairá desta linha de raciocínio, pois tem como base cenários propícios para a implementação dos padrões que aqui serão abordados: Adapter e Interpreter.

O primeiro cenário configura-se a partir da necessidade de utilizar uma funcionalidade por parte do programador. A princípio, a primeira ação é a de verificar se tal funcionalidade já existe evitando assim que uma nova e desnecessária funcionalidade seja escrita. Em alguns casos, a interface de uma classe pode não fornecer a funcionalidade desejada. Ao invés de modificar a interface para então prover a funcionalidade desejada, pode-se criar um adaptador, que ficará responsável por fornecer novas funcionalidades ao desenvolvedor.

Em outro cenário, pode-se ter um problema relacionado à duplicação de código de validação de dados. Quando se tem muito código de validação de dados é interessante que este esteja centralizado em um local, como uma classe, para ser invocado quando necessário. Validar dados envolve interpretá-los primeiramente, e a criação de um interpretador pode ser muito útil neste sentido.

As técnicas de refatoração que o desenvolvedor deve conhecer para um melhor entendimento sobre as refatorações para padrões deste artigo são Extrair Classe, Extrair Método, Mover Método, Extrair Subclasse, Subir Método na Hierarquia, Extrair Superclasse e Internalizar Método (ver Nota 1). Uma breve descrição dos padrões Adapter e Interpreter também será apresentada antes de iniciar o processo de aprendizagem das refatorações para padrões.

Nota 1. Refatorações apresentadas em outros artigos

As técnicas de refatoração Extrair Classe, Extrair Método, Mover Método, Extrair Subclasse, Subir Método na Hierarquia, Extrair Superclasse e Internalizar Método já foram apresentadas em outras edições da Engenharia de Software Magazine, mais precisamente nas edições de número 29, 30, 33 e 34.

O padrão de projeto Adapter

Nome do padrão de projeto: Adapter. Pertencente ao conjunto dos padrões de projeto classificados como Padrões Estruturais.

O problema: Em determinado momento no desenvolvimento de uma aplicação, o desenvolvedor pode se deparar com a necessidade de utilizar uma classe e perceber que sua interface não provê as funcionalidades que ele precisa. O padrão Adapter atua neste contexto, permitindo ao desenvolvedor, ao invés de modificar a interface da classe, criar um adaptador, que será responsável por adaptar a interface que não corresponde às necessidades do desenvolvedor em uma que corresponda.

As consequências: Como consequência, tem-se uma aplicação cujas classes podem ser mais bem utilizadas, dado que ao se criar um adaptador, a utilidade da classe aumenta, mediante aos novos recursos que ela proverá.

...
Quer ler esse conteúdo completo? Tenha acesso completo