ARTIGO ORIGINAL
DENDASCK, Luiz Miguel [1], ALVES, Anderson Pinto [2], PRATES, Jairo de Araujo [3]
DENDASCK, Luiz Miguel. ALVES, Anderson Pinto. PRATES, Jairo de Araujo. Refatoração para padrões: Aplicação de strategy, factory method e observer no módulo de checkout de um sistema de comércio eletrônico. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano. 11, Ed. 08, Vol. 01, pp. 33-58. Agosto de 2026. ISSN: 2448-0959. Disponível em: https://www.nucleodoconhecimento.com.br/engenharia-de-software/refatoracao-para-padroes, DOI: https://doi.org/10.5281/zenodo.21894453
RESUMO
O comércio eletrônico impõe aos sistemas de venda on-line elevada taxa de mudança em regras de negócio como meios de pagamento, modalidades de frete e obrigações fiscais. Em módulos de checkout construídos sem separação clara de responsabilidades, essa variabilidade se acumula sob a forma de longas cadeias condicionais, elevando o custo e o risco de cada manutenção. Este trabalho investiga em que medida a adoção de padrões de projeto reduz esse custo. O objetivo geral foi refatorar o módulo de checkout de um sistema de comércio eletrônico empregando os padrões Strategy, Factory Method e Observer, e avaliar objetivamente o efeito da intervenção sobre a manutenibilidade. Adotou-se relato de experiência de abordagem qualitativa com apoio quantitativo, organizado em seis etapas: caracterização da versão legada, identificação dos pontos de variação, pesquisa bibliográfica, seleção justificada dos padrões, implementação em Python e medição comparativa por complexidade ciclomática e índice de manutenibilidade, com verificação da equivalência funcional em quatro cenários de pedido. A complexidade ciclomática do método central caiu de 20 para 1 e a média do projeto passou de 11,00 para 1,71; o índice de manutenibilidade médio subiu de 58,68 para 63,82, permanecendo idênticos os resultados dos quatro cenários. A inclusão de um novo meio de pagamento passou a exigir essencialmente código novo, sem alteração das classes de negócio existentes. Como contribuição, o trabalho documenta um roteiro replicável de refatoração para padrões e discute criticamente suas limitações, entre elas o aumento expressivo do número de classes.
Palavras-chave: Padrões de projeto, Refatoração, Manutenibilidade.
1. INTRODUÇÃO
O desenvolvimento de sistemas de comércio eletrônico é hoje uma das frentes de trabalho mais comuns do engenheiro de software brasileiro. Diferentemente de domínios estáveis, a operação de uma loja virtual muda com frequência: novos meios de pagamento são incorporados, transportadoras entram e saem da malha logística, promoções alteram a política de frete e obrigações fiscais impõem novos comportamentos ao fechamento do pedido. O módulo de checkout cujo é responsável por consolidar o carrinho, cotar o frete, cobrar o cliente e disparar os efeitos da confirmação, concentra boa parte dessa variabilidade e, por consequência, boa parte do esforço de manutenção do produto.
Quando esse módulo é escrito sem uma separação explícita entre o que é estável e o que varia, a variabilidade tende a se materializar como cadeias condicionais encadeadas dentro de um único método. O resultado é conhecido na prática profissional: um método longo, difícil de testar isoladamente, no qual qualquer inclusão de regra exige editar código que já está em produção. Cada alteração passa então a carregar risco de regressão sobre funcionalidades que nada têm a ver com a mudança pretendida, e o tempo de resposta da equipe a demandas de negócio se deteriora progressivamente.
Diante desse cenário, formulou-se a seguinte pergunta de pesquisa: em que medida a aplicação de padrões de projeto no módulo de checkout de um sistema de comércio eletrônico reduz, de forma mensurável, a complexidade estrutural e o esforço necessário para incorporar novas regras de negócio, sem alterar o comportamento observável do sistema? A pergunta é relevante porque a literatura técnica costuma apresentar os padrões de projeto como benefício evidente, ao passo que a literatura científica registra resultados mais matizados, o que justifica a verificação empírica em um caso concreto.
O objetivo geral deste trabalho é refatorar o módulo de checkout de um sistema de comércio eletrônico, empregando os padrões de projeto Strategy, Factory Method e Observer, do catálogo GoF, e avaliar objetivamente o efeito dessa intervenção sobre a manutenibilidade do módulo.
Como objetivos específicos, delimitaram-se: (a) caracterizar a arquitetura da versão legada e identificar seus pontos de variação; (b) pesquisar, em fontes técnicas e científicas, padrões candidatos ao tratamento desses pontos; (c) selecionar e justificar os padrões adequados ao contexto; (d) implementar a versão refatorada preservando o comportamento observável; (e) medir e comparar as duas versões por meio de métricas de produto; e (f) discutir criticamente os ganhos e as limitações da solução.
A escolha da linguagem Python 3 para o experimento decorre de três razões. Primeiro, por ser a linguagem em que o autor tem maior fluência, o que reduz o risco de que dificuldades de sintaxe se confundam com dificuldades de projeto. Segundo, por possuir suporte nativo a classes abstratas por meio do módulo abc, o que permite expressar as interfaces exigidas pelos padrões sem recursos externos. Terceiro, por dispor de ferramental maduro e gratuito de análise estática, em especial a biblioteca Radon, capaz de produzir as métricas de complexidade e manutenibilidade utilizadas na avaliação. Registre-se que os padrões aplicados independem da linguagem, tendo sido originalmente catalogados em C++ e Smalltalk.
O artigo está organizado da seguinte forma: a fundamentação teórica apresenta o conceito de padrão de projeto, descreve os três padrões utilizados, discute a refatoração para padrões e as métricas empregadas, e revisa estudos correlatos; a metodologia detalha o percurso seguido, as ferramentas e o ambiente; os resultados apresentam as arquiteturas anterior e posterior, os trechos de código correspondentes e os valores medidos; a conclusão retoma os objetivos e aponta trabalhos futuros.
2. FUNDAMENTAÇÃO TEÓRICA
O conceito de padrão como unidade de solução recorrente não nasceu na computação. Ele foi formulado pelo arquiteto Christopher Alexander, que descreveu configurações espaciais recorrentes em cidades e edifícios (Alexander; Ishikawa; Silverstein, 1977), e foi transposto para o projeto de software pelo grupo conhecido como Gang of Four. Segundo Gamma et al. (2000), um padrão de projeto nomeia, abstrai e identifica os aspectos essenciais de uma estrutura de projeto recorrente, tornando-a reutilizável em contextos distintos. A contribuição do padrão, portanto, não é código pronto, mas a descrição de uma solução em nível de projeto, acompanhada das forças que a justificam e das consequências de adotá-la.
Valente sintetiza essa ideia ao afirmar que “padrões de projeto descrevem objetos e classes que se relacionam para resolver um problema de projeto genérico em um contexto particular” (Valente, 2020, cap. 6). O autor associa os padrões ao princípio do design for change, isto é, ao reconhecimento de que sistemas de software mudam continuamente e de que essa mudança deve ser antecipada no projeto, e não tratada como exceção. É essa perspectiva de projetar para a mudança que orienta a intervenção relatada neste trabalho.
O catálogo original organiza vinte e três padrões em três famílias, conforme a finalidade. Os padrões de criação tratam do processo de instanciação de objetos; os estruturais tratam da composição de classes e objetos; e os comportamentais tratam da atribuição de responsabilidades e da comunicação entre objetos (Gamma et al., 2000). Atravessa todo o catálogo o princípio de programar para uma interface, e não para uma implementação, que consiste em fazer o cliente depender de um tipo abstrato, de modo que a substituição da implementação concreta não o afete.
Esse princípio guarda relação direta com o Princípio Aberto/Fechado, segundo o qual uma entidade de software deve estar aberta para extensão e fechada para modificação. Martin (2019) argumenta que o objetivo de uma boa arquitetura é justamente permitir que o comportamento do sistema seja ampliado sem que o código já existente precise ser alterado, reduzindo o custo e o risco de cada mudança. Padrões como Strategy e Factory Method são, nesse sentido, mecanismos concretos de realização desse princípio.
O padrão Strategy é um padrão comportamental cujo propósito é definir uma família de algoritmos, encapsular cada um deles e torná-los intercambiáveis, permitindo que o algoritmo varie independentemente dos clientes que o utilizam (Gamma et al., 2000). Valente (2020) explica que “o objetivo do padrão é parametrizar os algoritmos usados por uma classe” (Valente, 2020), sendo recomendado quando existem diversas alternativas com o mesmo propósito e não se deseja antecipar a escolha de uma delas. Em termos práticos, o padrão substitui a seleção condicional de comportamento pelo polimorfismo.
O padrão Factory Method é um padrão de criação que define uma interface para criar um objeto, mas transfere às subclasses a decisão sobre qual classe concreta instanciar (Gamma et al., 2000). Sua utilidade aparece quando o código cliente precisa produzir objetos de uma família cuja composição pode crescer: em vez de espalhar chamadas a construtores concretos pelo sistema, concentra-se a decisão de criação em criadores especializados. O padrão é frequentemente empregado em conjunto com Strategy, pois alguém precisa decidir qual estratégia concreta será entregue ao contexto.
O padrão Observer, também comportamental, define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente (Gamma et al., 2000). Valente (2020) descreve que “esse padrão define como implementar uma relação do tipo um-para-muitos entre objetos sujeito e observadores” (Valente, 2020, cap. 6), sendo os observadores notificados quando o estado do sujeito muda. O efeito de projeto mais relevante é a inversão da dependência: o sujeito deixa de conhecer os serviços concretos que reagem ao evento e passa a conhecer apenas a abstração do observador.
A introdução de padrões em um sistema já existente é um caso particular de refatoração. Kerievsky (2008) propõe o termo refatoração para padrões para designar a prática de conduzir, por passos pequenos e seguros, um projeto existente até uma estrutura descrita por um padrão, em oposição à aplicação antecipada de padrões antes que a necessidade se manifeste. A condição essencial dessa prática é a preservação do comportamento observável: altera-se a estrutura interna sem alterar o que o sistema entrega ao usuário. Larman (2011) reforça que a atribuição adequada de responsabilidades entre objetos é anterior à escolha do padrão, e que padrões mal atribuídos apenas deslocam o problema.
Para que o efeito de uma refatoração não permaneça no campo da opinião, é necessário quantificá-lo. Duas métricas de produto são usuais nesse contexto. A complexidade ciclomática, proposta por McCabe (1976), mede o número de caminhos linearmente independentes em uma unidade de código e cresce a cada estrutura de decisão, sendo um indicador direto do esforço de teste e de compreensão. O Índice de Manutenibilidade combina, em um único valor, medidas de volume propostas por Halstead (1977), a complexidade ciclomática e o número de linhas de código, sintetizando a facilidade com que o código pode ser modificado. Ambas foram utilizadas na avaliação apresentada na seção de resultados.
No cenário brasileiro, Cagnin et al. (1999) já haviam demonstrado, ainda na década de 1990, que padrões de projeto podem ser incorporados a processos de reengenharia de sistemas legados, atuando como alvo arquitetural da reestruturação. O trabalho é relevante para esta pesquisa porque estabelece que a aplicação de padrões não se restringe a projetos novos, podendo orientar a recuperação de sistemas em operação que é exatamente a situação do módulo aqui analisado.
Ferreira, Resende e Costa (2012) conduziram experimento próximo ao aqui relatado, refatorando um módulo legado de um sistema de gestão ambiental com os padrões Factory, Template, Singleton e Command, e medindo o resultado por métricas de Halstead, complexidade ciclomática e Índice de Manutenibilidade. Os autores registram que “os resultados de todas as métricas aplicadas ao sistema refatorado foram satisfatórios em relação aos resultados obtidos pelo sistema legado” (Ferreira; Resende; Costa, 2012, p. 347): a complexidade ciclomática caiu de 35,55 para 5,42 e o Índice de Manutenibilidade passou de -7,72 para 20,48. O presente trabalho difere daquele por operar sobre um domínio distinto, por empregar outro conjunto de padrões, dois deles comportamentais e por acrescentar uma medição do esforço de extensão, ausente naquele estudo.
Santos, Souza e Figueiredo (2016) investigaram a percepção de desenvolvedores Java sobre o uso de padrões e concluíram que “os três maiores benefícios obtidos a partir da utilização de padrões de projeto são: (i) facilitar na manutenção e evolução do código, (ii) dar apoio na solução de problemas e (iii) favorecer a reutilização de soluções” (Santos; Souza; Figueiredo, 2016, p. 37). Os mesmos autores identificam, contudo, que “os prazos curtos e a falta de conhecimento sobre padrões de projeto são os principais fatores que dificultam a utilização de padrões de projeto” (Santos; Souza; Figueiredo, 2016, p. 37). Trata-se de estudo de percepção; o presente trabalho complementa-o ao produzir evidência objetiva sobre um artefato concreto.
A literatura internacional recomenda cautela. A revisão sistemática de Zhang e Budgen (2012) concluiu que a evidência empírica sobre a efetividade dos padrões ainda é limitada e que os benefícios não se distribuem uniformemente entre eles: alguns padrões apresentam ganhos consistentes de manutenibilidade, enquanto outros aumentam a dificuldade de compreensão por desenvolvedores menos experientes. Wedyan e Abufakher (2020), em revisão sistemática mais recente, reiteram que o impacto dos padrões sobre atributos de qualidade depende do padrão específico, do contexto de aplicação e da experiência da equipe, não havendo suporte para a afirmação de que padrões melhoram a qualidade de forma indiscriminada.
Essa ressalva é explicitada por Valente (2020) nos seguintes termos:
O maior risco de padrões de projetos é a sua super-aplicação. Nem todo problema precisa ser resolvido por meio dos padrões de projeto; por isso, não tente forçar um problema a caber em um padrão de projeto quando uma abordagem tradicional funcionar melhor. (Valente, 2020, cap. 6)
Portanto, a fundamentação aqui reunida sustenta duas decisões metodológicas adotadas neste trabalho: aplicar apenas os padrões cuja necessidade fosse demonstrável a partir de um problema efetivamente observado no código legado, e submeter o resultado a medição objetiva em vez de avaliá-lo por impressão. O diferencial desta experiência em relação aos estudos revisados está na combinação de três elementos: um domínio de alta variabilidade de regras de negócio, o uso conjunto de dois padrões comportamentais e um de criação, e a medição explícita do esforço de extensão como evidência complementar às métricas estruturais.
3. METODOLOGIA
Quanto ao método, este trabalho caracteriza-se como um relato de experiência, modalidade adequada quando o pesquisador é também o agente da intervenção descrita e o interesse recai sobre o percurso adotado e seus efeitos verificáveis. A abordagem é predominantemente qualitativa, uma vez que a seleção dos padrões decorreu de análise interpretativa da arquitetura existente, mas incorpora apoio quantitativo, pois as conclusões sobre o efeito da intervenção foram submetidas a medição por métricas de produto.
Quanto aos fins, a pesquisa é aplicada e explicativa; quanto aos meios, combina pesquisa bibliográfica e pesquisa experimental. A etapa bibliográfica consistiu no levantamento de livros de referência e de artigos científicos publicados em anais de eventos da Sociedade Brasileira de Computação e em periódicos internacionais indexados, consultados por meio do Portal SOL/SBC, do Google Acadêmico e da biblioteca virtual da instituição. A etapa experimental consistiu na refatoração propriamente dita e na coleta de métricas sobre as duas versões do código.
O objeto de estudo é o módulo de checkout de um sistema de comércio eletrônico de pequeno porte, ao qual o autor tem acesso. O módulo foi isolado do restante do sistema e reconstruído em um projeto autônomo, preservando integralmente as regras de negócio originais, cotação de frete por modalidade, cobrança por meio de pagamento, política de frete grátis, acréscimo de parcelamento, taxa antifraude e os efeitos colaterais da confirmação do pedido. Essa delimitação foi necessária para que as métricas refletissem exclusivamente o efeito da intervenção, sem interferência de código alheio ao escopo.
O percurso foi organizado em seis etapas sequenciais. Na primeira, procedeu-se à leitura integral do módulo legado e à documentação de sua arquitetura por meio de um diagrama de classes. Na segunda, foram identificados os pontos de variação, entendidos como os locais em que o código decide entre comportamentos alternativos: a cadeia condicional de modalidades de frete, a cadeia condicional de meios de pagamento e o bloco de efeitos colaterais executados após a confirmação. Na terceira etapa, foram pesquisados padrões candidatos ao tratamento de cada ponto de variação, com apoio da bibliografia referida na seção anterior.
Na quarta etapa realizou-se a seleção justificada dos padrões. Adotou-se como critério que cada padrão só seria aplicado se houvesse um problema concreto observado no código legado que ele resolvesse, critério derivado da advertência de Valente (2020) quanto à super-aplicação. Assim, selecionou-se Strategy para as duas cadeias condicionais, por se tratar exatamente de famílias de algoritmos intercambiáveis; Factory Method para a criação das estratégias, uma vez que a substituição das cadeias condicionais deslocaria para o cliente a decisão sobre qual objeto instanciar; e Observer para os efeitos colaterais da confirmação, por configurarem uma relação um-para-muitos entre o evento de pedido confirmado e serviços independentes entre si. Foram descartados, nesta etapa, os padrões Singleton, por não haver requisito de instância única e Decorator, cuja aplicação a acréscimos de preço foi considerada desproporcional ao problema.
Na quinta etapa realizou-se a implementação. As classes foram criadas em módulos separados, de acordo com a responsabilidade, e a refatoração foi conduzida em passos pequenos, verificando-se a cada passo a manutenção do comportamento. Na sexta etapa procedeu-se à avaliação, dividida em três frentes: verificação de equivalência funcional, medição estrutural e medição do esforço de extensão.
A verificação de equivalência funcional foi realizada por meio de um roteiro automatizado que submete as duas versões aos mesmos quatro cenários de pedido, combinando modalidades de frete e meios de pagamento distintos, e compara os valores de total, prazo de entrega e status retornados. Os serviços externos de estoque, e-mail, SMS, emissor fiscal e log, foram substituídos por dublês de teste, de modo que a execução não dependesse de infraestrutura externa.
A medição estrutural utilizou a biblioteca Radon, que implementa o cálculo da complexidade ciclomática de McCabe e do Índice de Manutenibilidade. Foram coletados, para as duas versões, a complexidade do método central, a complexidade média por bloco e o Índice de Manutenibilidade por arquivo. A medição do esforço de extensão consistiu em implementar, em ambas as versões, um requisito novo e realista a inclusão de um quarto meio de pagamento, a carteira digital e contabilizar, por meio de comparação de arquivos, quantas linhas foram acrescentadas e quantas linhas preexistentes precisaram ser alteradas.
Quanto aos instrumentos e ao ambiente, o experimento foi conduzido em ambiente Linux com Python 3, utilizando a biblioteca padrão para as abstrações em especial o módulo abc para a definição de classes abstratas, a biblioteca Radon para a análise estática e a ferramenta Graphviz para a geração dos diagramas de classes apresentados na próxima seção. Não foram utilizadas bibliotecas de terceiros na implementação do módulo, a fim de que os resultados medidos não fossem influenciados por código externo. Todo o código produzido é original do autor e encontra-se reproduzido, em seus trechos essenciais, na seção de resultados.
4. RESULTADOS E DISCUSSÃO
Esta seção apresenta a arquitetura do módulo antes e depois da intervenção, os trechos de código que materializam cada padrão aplicado e os valores medidos nas duas versões, encerrando com a discussão crítica dos achados e o registro das limitações observadas.
A Figura 1 documenta a arquitetura da versão legada. O módulo era composto por uma única classe, ProcessadorPedido, acoplada diretamente a cinco serviços concretos — repositório de estoque, serviço de e-mail, serviço de SMS, serviço fiscal e serviço de log — recebidos por construtor. O pedido trafegava como um dicionário sem comportamento, configurando o que a literatura denomina modelo de domínio anêmico. Toda a lógica de negócio concentrava-se no método processar.
Figura 1 – Diagrama de classes da arquitetura anterior à refatoração
O Quadro 1 reproduz o núcleo desse método. Observa-se que a decisão sobre a modalidade de frete, a decisão sobre o meio de pagamento e o encadeamento dos efeitos colaterais da confirmação ocorrem no mesmo escopo, entremeados por regras de negócio específicas de cada ramo. Note-se ainda a repetição da verificação do meio de pagamento: a informação já consumida na cadeia de cobrança é consultada novamente no bloco de notificações, para decidir o envio de SMS. Essa duplicação é sintomática, a estrutura obriga o código a perguntar duas vezes a mesma coisa porque não há um objeto responsável por respondê-la.
Quadro 1 – Trecho do método processar na versão legada
A análise estática confirmou o diagnóstico visual. O método processar apresentou complexidade ciclomática igual a 20, valor classificado pela ferramenta na faixa C, indicativa de código que demanda atenção. A classe como um todo atingiu complexidade 12 e a média do projeto ficou em 11,00, distribuída em apenas três blocos analisáveis. Em termos práticos, testar exaustivamente esse método exigiria percorrer vinte caminhos independentes, e qualquer alteração em uma modalidade de frete obrigaria a reabrir o mesmo escopo que trata da emissão da nota fiscal.
A Figura 2 apresenta a arquitetura resultante da refatoração, no que se refere aos padrões Strategy e Factory Method. As duas cadeias condicionais foram substituídas por duas famílias polimórficas: EstrategiaFrete, com as implementações FreteSedex, FretePac, FreteRetiradaEmLoja e FreteExpressoLocal; e EstrategiaPagamento, com PagamentoCartaoCredito, PagamentoBoleto e PagamentoPix. A obtenção de cada estratégia concreta foi atribuída a criadores especializados, CriadorFrete e CriadorPagamento e suas subclasses, de modo que o ServicoCheckout não conhece nenhuma classe concreta de frete ou de pagamento.
Figura 2 – Diagrama de classes posterior à refatoração: padrões Strategy e Factory Method
O Quadro 2 exibe a aplicação do padrão Strategy à cotação de frete. A classe abstrata EstrategiaFrete declara a operação cotar, e cada modalidade a implementa com sua própria regra. O ponto relevante do arranjo é que a inclusão de uma nova modalidade passa a exigir apenas uma nova classe que implemente a interface, sem que qualquer linha das modalidades já existentes ou do serviço de checkout precise ser alterada, evidência medida e apresentada adiante, na Tabela 2. Trata-se da realização concreta do Princípio Aberto/Fechado discutido por Martin (2019) na fundamentação teórica: o comportamento do sistema passa a ser estendido por acréscimo, e não por modificação.
Quadro 2 – Aplicação do padrão Strategy à cotação de frete
O Quadro 3 apresenta a aplicação do padrão Factory Method. A classe abstrata CriadorPagamento declara o método de fabricação criar_estrategia e, sobre ele, define a operação de negócio processar_cobranca, que utiliza o produto sem conhecer sua classe concreta. Cada criador concreto responde pela instanciação de uma estratégia. O dicionário CRIADORES_PAGAMENTO associa o código recebido na requisição ao criador correspondente, reduzindo a resolução do meio de pagamento a uma consulta indexada. Cabe registrar que essa consulta preserva um único ponto de decisão no sistema, agora isolado em uma função de três linhas, em contraste com a cadeia condicional de quatro ramos da versão anterior.
Quadro 3 – Aplicação do padrão Factory Method à criação das estratégias de pagamento
A Figura 3 documenta a aplicação do padrão Observer aos efeitos colaterais da confirmação do pedido, e o Quadro 4 exibe o código correspondente. A classe PublicadorPedido desempenha o papel de sujeito, mantendo a lista de inscritos e disparando a notificação; a interface ObservadorPedido define o contrato de reação; e cada efeito antes embutido no método processar tornou-se um observador autônomo, ObservadorEstoque, ObservadorEmail, ObservadorSms, ObservadorFiscal e ObservadorAuditoria. O ganho de projeto é que um novo efeito colateral passa a ser incorporado por inscrição de um novo observador, sem alteração do serviço de checkout nem dos observadores já existentes, o que evidencia o desacoplamento obtido.
Figura 3 – Diagrama de classes do padrão Observer aplicado aos efeitos da confirmação
Quadro 4 – Aplicação do padrão Observer aos efeitos colaterais da confirmação do pedido
O Quadro 5 exibe o resultado dessa reorganização sobre a classe de contexto. O método processar do ServicoCheckout passou a conter doze linhas e nenhuma estrutura de decisão: ele obtém a cotação de frete, delega a cobrança ao criador de pagamento e publica o evento de confirmação. Toda a variabilidade que antes ocupava o corpo do método migrou para colaboradores substituíveis, e o serviço passou a depender exclusivamente de abstrações.
Quadro 5 – Classe de contexto após a refatoração
A Tabela 1 consolida a comparação estrutural entre as duas versões. A complexidade ciclomática do método central caiu de 20 para 1, e os blocos mais complexos do projeto refatorado a estratégia de cartão de crédito, que ainda concentra as regras de parcelamento, e a estratégia do PAC, que concentra a política de frete grátis, apresentam complexidade 4, valor cinco vezes menor que o do método monolítico substituído. A média por bloco caiu de 11,00 para 1,71, o que significa que a complexidade não foi apenas deslocada de um ponto a outro, mas efetivamente diluída em unidades pequenas e testáveis isoladamente.
Tabela 1 – Comparação estrutural entre as versões legada e refatorada
O Índice de Manutenibilidade médio subiu de 58,68 para 63,82. A magnitude do ganho é moderada e merece leitura cuidadosa, retomada adiante na discussão das limitações. Já o volume de código cresceu de forma expressiva: as linhas lógicas passaram de 74 para 206 e o número de classes, de 1 para 30. Esse crescimento é a contrapartida esperada da substituição de condicionais por polimorfismo e constitui o principal custo da solução adotada.
A Tabela 2 apresenta a medição do esforço de extensão, realizada com a inclusão de um quarto meio de pagamento — a carteira digital — em ambas as versões. Na versão legada, o requisito exigiu editar a classe ProcessadorPedido em dois pontos distintos dentro do método central: o acréscimo de um novo ramo na cadeia de cobrança e a alteração da condição que decide o envio de SMS. Na versão refatorada, o mesmo requisito foi atendido pela criação de uma nova classe de estratégia, de um novo criador e do registro correspondente, sem que qualquer classe de negócio preexistente fosse modificada; a única linha alterada foi a declaração de importação.
Tabela 2 – Esforço de extensão para a inclusão de um novo meio de pagamento
A distinção entre linhas acrescentadas e linhas modificadas é o dado mais significativo dessa medição. Em termos absolutos, a versão refatorada exigiu mais linhas de quinze contra sete. Em termos de risco, porém, as situações não são comparáveis: na versão legada, as oito linhas tocadas encontram-se no interior de um método responsável por todos os pedidos do sistema, de modo que um erro de digitação afeta pagamentos por cartão, boleto e PIX; na versão refatorada, o código novo está confinado em classes que só são executadas quando a carteira digital é selecionada. É esse deslocamento de modificação para acréscimo que traduz, em termos operacionais, o benefício apontado por Santos, Souza e Figueiredo (2016) quanto à facilidade de manutenção e evolução do código.
A Tabela 3 registra a verificação de equivalência funcional. Os quatro cenários, combinando modalidades de frete e meios de pagamento distintos e incluindo uma unidade da federação sujeita a acréscimo regional, produziram valores idênticos de total, prazo e status nas duas versões. Confirma-se, portanto, a condição essencial da refatoração enunciada por Kerievsky (2008): a estrutura interna foi alterada sem que o comportamento observável do sistema sofresse modificação.
Tabela 3 – Verificação da equivalência funcional entre as duas versões
Os resultados obtidos são coerentes com os de Ferreira, Resende e Costa (2012), que também registraram queda expressiva da complexidade ciclomática após a introdução de padrões em um sistema legado. A magnitude, contudo, difere: naquele estudo o Índice de Manutenibilidade saltou de -7,72 para 20,48, variação muito superior à aqui observada. A explicação plausível está no ponto de partida. O sistema analisado por aqueles autores encontrava-se em faixa crítica de manutenibilidade, ao passo que o módulo aqui refatorado já apresentava índice razoável antes da intervenção. Ganhos marginais decrescentes são, nesse sentido, esperados: padrões de projeto produzem efeito mais visível sobre código em estado degradado.
Esse achado dialoga diretamente com a cautela expressa por Zhang e Budgen (2012) e por Wedyan e Abufakher (2020). A evidência aqui produzida não autoriza afirmar que padrões de projeto melhoram a qualidade em qualquer circunstância; autoriza afirmar que, neste módulo, diante deste problema específico — variabilidade de regras de negócio concentrada em condicionais —, os três padrões selecionados reduziram a complexidade estrutural e converteram esforço de modificação em esforço de acréscimo.
Cabe destacar a complementaridade entre os padrões utilizados. Strategy resolveu a variabilidade de comportamento, mas, isoladamente, transferiria ao cliente a decisão sobre qual estratégia instanciar, reintroduzindo a cadeia condicional em outro lugar. Factory Method absorveu essa decisão. Observer, por sua vez, atuou sobre um problema de natureza distinta não a escolha entre alternativas, mas a notificação simultânea de múltiplos interessados. A experiência sugere que a seleção de padrões deve partir da natureza do ponto de variação, e não de uma preferência prévia por determinado padrão.
Quanto às limitações, três merecem registro. A primeira é o custo em volume de código: o módulo passou de um arquivo com uma classe para cinco arquivos com trinta classes. Para equipes pequenas ou para módulos com baixa expectativa de mudança, esse custo pode não se justificar, o que reforça a advertência de Valente (2020) sobre a super-aplicação de padrões reproduzida na fundamentação teórica.
A segunda limitação é que o Índice de Manutenibilidade não melhorou de modo uniforme. O arquivo de observadores registrou índice de 56,49, valor inferior ao da versão legada monolítica, de 58,68. A causa provável é a forma de cálculo da métrica, que penaliza arquivos com muitas definições curtas e baixa densidade de comentários. O caso é ilustrativo de um risco metodológico: métricas de produto são indicadores, não veredictos, e sua leitura isolada pode induzir conclusões equivocadas.
A terceira limitação é de escopo, e tem duas faces. A primeira diz respeito à cobertura da verificação funcional: os quatro cenários exercitaram as modalidades SEDEX, PAC e retirada em loja, deixando de exercitar a modalidade expressa local, justamente a única que possui regra de exceção por unidade da federação. A segunda é que a avaliação restringiu-se a métricas de produto e ao esforço de extensão medido em linhas; não foram avaliados atributos que dependem de observação humana, como o tempo efetivo de compreensão do código por desenvolvedores que não participaram da refatoração. Esse é precisamente o aspecto no qual Zhang e Budgen (2012) identificam maior divergência de resultados na literatura, e sua verificação exigiria experimento com participantes, fora do alcance deste trabalho.
Por fim, quanto à transferibilidade, a solução aqui descrita não é específica do comércio eletrônico. A combinação Strategy com Factory Method aplica-se a qualquer contexto em que regras equivalentes variem por parâmetro de cálculo de tributos por regime, políticas de desconto por perfil de cliente, regras de reposição de estoque por categoria de produto. Da mesma forma, o padrão Observer aplica-se a qualquer evento de domínio que precise acionar serviços independentes entre si, como a conclusão de uma matrícula acadêmica ou a aprovação de um documento em fluxo de trabalho.
5. CONCLUSÃO
Este trabalho relatou a refatoração do módulo de checkout de um sistema de comércio eletrônico mediante a aplicação dos padrões de projeto Strategy, Factory Method e Observer, com avaliação objetiva do efeito da intervenção sobre a manutenibilidade.
Quanto aos resultados, a complexidade ciclomática do método central caiu de 20 para 1 e a média por bloco passou de 11,00 para 1,71; o Índice de Manutenibilidade médio subiu de 58,68 para 63,82; e a inclusão de um novo meio de pagamento deixou de exigir a edição de classes de negócio existentes, passando a demandar essencialmente código novo. A equivalência funcional foi confirmada nos quatro cenários avaliados, o que caracteriza a intervenção como refatoração no sentido estrito do termo.
Quanto aos objetivos, considera-se que foram atingidos, com uma ressalva. A arquitetura legada foi caracterizada e seus pontos de variação identificados; padrões candidatos foram pesquisados em fontes técnicas e científicas; a seleção foi justificada a partir de problemas efetivamente observados no código; a implementação preservou o comportamento observável; as duas versões foram medidas e comparadas; e os ganhos e limitações foram discutidos criticamente. O objetivo de discussão crítica foi atingido de forma parcial no que se refere aos atributos dependentes de percepção humana, cuja avaliação exigiria experimento com participantes.
A experiência evidencia que a importância dos padrões de projeto não reside na elegância da estrutura produzida, mas no deslocamento que promovem na natureza do trabalho de manutenção: de alterar código em produção para acrescentar código novo. Esse deslocamento reduz o risco de regressão, encurta o ciclo de resposta a demandas de negócio e torna previsível o custo de evolução do sistema atributos diretamente valorizados no exercício profissional da engenharia de software.
Do ponto de vista prático, o roteiro adotado de caracterizar, identificar pontos de variação, pesquisar, selecionar com justificativa, implementar em passos pequenos e medir é replicável em qualquer módulo que apresente sintomas semelhantes, independentemente do domínio ou da linguagem de programação. A principal recomendação decorrente da experiência é que a aplicação de padrões seja precedida da identificação de um problema concreto, sob pena de a solução tornar-se mais custosa que o problema que pretendia resolver.
Como aprendizado pessoal, destaca-se a percepção de que a seleção do padrão adequado depende menos do conhecimento do catálogo e mais da capacidade de nomear corretamente o ponto de variação existente no código. Uma vez nomeado o problema, a escolha do padrão torna-se quase imediata.
Para trabalhos futuros, indicam-se três direções. A primeira é a avaliação do padrão Decorator para a composição de acréscimos e descontos sobre o valor do pedido, hipótese descartada nesta experiência por falta de evidência de necessidade, mas que se tornaria pertinente com o crescimento das regras promocionais. A segunda é a replicação do experimento com participantes, medindo o tempo de compreensão e de alteração do código nas duas versões, de modo a complementar as métricas de produto com evidência de percepção. A terceira é a extensão da análise a métricas de acoplamento e coesão, que permitiriam avaliar dimensões de qualidade não capturadas pelas métricas utilizadas neste estudo.
REFERÊNCIAS BIBLIOGRÁFICAS
ALEXANDER, Christopher; ISHIKAWA, Sara; SILVERSTEIN, Murray. A pattern language: towns, buildings, construction. New York: Oxford University Press, 1977.
CAGNIN, Maria Istela; PENTEADO, Rosângela D.; GERMANO, Fernão S. R.; MASIERO, Paulo C. Reengenharia com uso de padrões de projeto. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE (SBES), 13., 1999, Florianópolis.
Anais […]. Porto Alegre: Sociedade Brasileira de Computação, 1999. p. 244-259. Disponível em: https://sol.sbc.org.br/index.php/sbes/issue/view/1075. Acesso em: 31 jul. 2026.
FERREIRA, Isaias Alves; RESENDE, Antônio Maria P. de; COSTA, Heitor A. Xavier. Análise do impacto da aplicação de padrões de projeto na manutenibilidade de um sistema orientado a objetos. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE (SBQS), 11., 2012, Fortaleza. Anais […]. Porto Alegre: Sociedade Brasileira de Computação, 2012. p. 341-348. DOI: 10.5753/sbqs.2012.15327. Disponível em: https://sol.sbc.org.br/index.php/sbqs/article/view/15327. Acesso em: 31 jul. 2026.
GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.
HALSTEAD, Maurice H. Elements of software science. New York: Elsevier, 1977. KERIEVSKY, Joshua. Refatoração para padrões. Porto Alegre: Bookman, 2008.
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2011.
MARTIN, Robert C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio de Janeiro: Alta Books, 2019.
McCABE, Thomas J. A complexity measure. IEEE Transactions on Software Engineering, New York, v. SE-2, n. 4, p. 308-320, 1976. DOI: 10.1109/TSE.1976.233837.
SANTOS, Marina Gabriela do Amaral; SOUZA, Mauricio Ronny de Almeida; FIGUEIREDO, Eduardo. Padrões de projeto em Java: um estudo prático sobre a utilização e benefícios. In: WORKSHOP SOBRE ASPECTOS SOCIAIS, HUMANOS E ECONÔMICOS DE SOFTWARE (WASHES), 1., 2016, Maceió. Anais […]. Porto Alegre:
Sociedade Brasileira de Computação, 2016. p. 31-40. Disponível em: https://sol.sbc.org.br/index.php/washes/article/view/6221. Acesso em: 31 jul. 2026.
VALENTE, Marco Tulio. Engenharia de software moderna: princípios e práticas para desenvolvimento de software com produtividade. Belo Horizonte: Edição do autor, 2020. Disponível em: https://engsoftmoderna.info. Acesso em: 31 jul. 2026.
WEDYAN, Fadi; ABUFAKHER, Somia. Impact of design patterns on software quality: a systematic literature review. IET Software, London, v. 14, n. 1, p. 1-17, 2020. DOI: 10.1049/iet-sen.2018.5446.
ZHANG, Cheng; BUDGEN, David. What do we know about the effectiveness of software design patterns? IEEE Transactions on Software Engineering, New York, v. 38, n. 5, p. 1213-1231, 2012. DOI: 10.1109/TSE.2011.79
INFORMAÇÕES SOBRE OS AUTORES
[1] Graduação em Administração, Graduando em Engenharia de Software e Especialista em Segurança da Informação.
[2] Professor regente.
[3] Professor mediador.
Contribuição dos autores:
Luiz Miguel Dendasck: Concepção, planejamento, análise, interpretação e redação do trabalho.
Anderson Pinto Alves: Orientação.
Jairo de Araujo Prates: Orientação.
INFORMAÇÕES SOBRE O MATERIAL
Conflito de interesse:
N/A.
Agradecimentos:
N/A.
Financiamento:
N/A.
Nota de presença de IA:
N/A.
Informações sobre Direitos Autorais e Licença:
Este é um artigo de Acesso Aberto distribuído sob os termos da Creative Commons Attribution License, que permite uso, distribuição e reprodução irrestritos em qualquer meio, desde que o autor e a fonte originais sejam creditados.
Os nomes e endereços informados nesta revista serão usados exclusivamente para os serviços prestados por esta publicação, não sendo disponibilizados para outras finalidades ou a terceiros.
- ISSN (versão eletrônica): 2448-0959
- Licença Creative Commons: Este trabalho está licenciado com uma Licença Creative Commons – Atribuição 4.0 Internacional.
Histórico da Publicação:
Material recebido: 27 de julho de 2026.
Material aprovado pelos pares: 03 de agosto de 2026.
Material editado aprovado pelos autores: 06 de agosto de 2026.
