Refatoração em C# WinForms — Um Olhar Mais Profundo com Tim Corey

O Que Refatoração Significa Nessa Lição

Às 0:02, Tim apresenta a Lição 24 e explica que refatoração significa retrabalhar o código para que ele desempenhe o mesmo trabalho, mas de uma forma melhor. Ele aponta que o aplicativo já funciona, mas contém 'lixo' e áreas que não estão à altura do padrão. Segundo Tim, este é o momento certo para limpar as coisas antes que o projeto cresça ainda mais.

Ele enfatiza que refatorar não é sobre adicionar recursos—é sobre melhorar estrutura, legibilidade e manutenibilidade a longo prazo enquanto mantém o comportamento o mesmo.

Limpando Valores de Retorno Desnecessários em Interfaces

Começando às 0:31, Tim mergulha na primeira refatoração: corrigindo assinaturas de métodos de interface. Ele explica que no início do projeto, os métodos estavam retornando modelos desnecessariamente. Visto que os objetos já são passados por referência, retornar o mesmo modelo novamente não tem propósito real.

Tim demonstra alterar esses métodos para void, o que imediatamente quebra as implementações. Ele explica por que isso acontece: quando uma interface muda, todas as classes que a implementam devem corresponder à nova assinatura exatamente. Ele percorre a correção do conector SQL e do conector de texto para alinhar com a interface atualizada.

Às 2h33, Tim faz uma pausa para mostrar o que acontece se você deixar o Visual Studio implementar automaticamente a interface. Ele explica por que ocorrem nomes de métodos duplicados e esclarece que apenas os tipos de retorno não são suficientes para diferenciar assinaturas de métodos.

Corrigindo Erros de Compilação Causados por Refatoração

Às 4:00, Tim compila a solução e mostra intencionalmente os erros que aparecem. Ele explica que esses erros são esperados e úteis. Por exemplo, o código que anteriormente esperava um modelo retornado agora falha porque o método retorna void.

Tim corrige isso removendo atribuições desnecessárias e recompilando a solução. Ele destaca que a refatoração geralmente causa interrupções de curto prazo, mas cada erro aponta diretamente para o código que precisa ser melhorado.

Migrando Constantes de Nome de Arquivo para o GlobalConfig

Começando às 5h25, Tim refatora a forma como os nomes de arquivos são tratados no conector de texto. Anteriormente, os caminhos dos arquivos eram armazenados como constantes de string privadas dentro da classe. Tim explica que isso não é mais necessário porque os nomes de arquivos já existem no GlobalConfig.

Ele substitui constantes locais por GlobalConfig.PeopleFile, GlobalConfig.PrizesFile e propriedades similares. Tim explica que essa mudança centraliza a configuração e garante que todo o aplicativo use caminhos de arquivo consistentes.

Ele também faz um ponto importante: evite refatorar muitas coisas ao mesmo tempo. Quando ele percebe melhorias adicionais que poderiam ser feitas, ele diz explicitamente que voltará a elas mais tarde.

Refatorando o Processador de Conector de Texto

Às 7h44, Tim continua refatorando removendo parâmetros de nome de arquivo de vários métodos no processador de conector de texto. Como os nomes de arquivo agora residem no GlobalConfig, passá-los adiante é redundante.

Tim atualiza cuidadosamente as assinaturas de métodos, substitui parâmetros por referências do GlobalConfig e se baseia na lista de erros do Visual Studio para guiá-lo. Ele explica que ver muitos erros de uma vez é normal durante a refatoração e não algo para entrar em pânico.

Às 13h16, ele observa como o monitoramento de erros em tempo real é útil ao limpar sistematicamente chamadas de métodos em todo o projeto.

Identificando a Lógica da Interface do Usuário que Está Fazendo Demais

Às 15h24, Tim destaca um grande problema de design: muita lógica dentro de um manipulador de eventos da interface do usuário. Ele percorre um evento de clique de botão e explica que ele contém muito mais código do que um evento deveria. No Windows Forms, ações do usuário como cliques em botões são tratadas por manipuladores de eventos, que definem a ação específica a ser executada quando o evento ocorre.

Tim explica que o código da interface do usuário deve se concentrar apenas na interação do usuário. O Windows Forms usa um modelo de programação orientado a eventos, onde as ações do usuário disparam eventos que são tratados pelo código do aplicativo. A lógica de negócios — como a pontuação de torneios e avanço de vencedores — pertence a uma biblioteca de classes. Essa separação permite que a mesma lógica seja reutilizada posteriormente em um aplicativo web ou aplicação WPF.

Extraindo a Lógica do Torneio para a Biblioteca de Classes

Começando às 17h55, Tim move a lógica de pontuação do torneio para um novo método público dentro da classe de lógica do torneio. Ele o nomeia UpdateTournamentResults e explica por que ele aceita todo o modelo de torneio, não apenas um confronto único.

Ele copia a lógica do formulário, cola na biblioteca de classes e ajusta para funcionar independentemente dos elementos da interface do usuário. Essa refatoração garante que as regras do torneio residam em um só lugar e possam ser reutilizadas em qualquer lugar.

Pontuando Confrontos e Lidando com Folgas Corretamente

Às 21h37, Tim refatora como os confrontos são pontuados. Em vez de trabalhar com um único confronto, ele percorre todas as rodadas e todos os confrontos, construindo uma lista de confrontos que precisam de pontuação.

Ele explica a lógica para detectar jogos concluídos e semanas de folga. Tim aponta que as semanas de folga eram anteriormente tratadas de maneira "improvisada" ao atribuir pontuações falsas. A refatoração permite que ele lide com folgas de forma explícita e limpa.

Extraindo a Pontuação em Métodos Privados

Às 28h17, Tim extrai a lógica de pontuação para um método privado. Ele explica que métodos menores e focados tornam o código mais fácil de entender e manter.

Ele também renomeia métodos para refletir melhor o que fazem, como mudar a lógica de pontuação para algo que claramente "marca vencedores em confrontos".

Determinação de Vencedor Configurável

Começando às 29h58, Tim refatora a lógica de determinação de vencedores para que possa lidar com cenários de vitória por maior pontuação e vitória por menor pontuação. Ele introduz uma nova configuração de aplicativo e explica por que a configuração é melhor do que regras codificadas de forma rígida.

Tim discute designs alternativos, incluindo armazenar esse valor no modelo de torneio, mas explica por que essa mudança está fora do escopo desta lição.

Avançando Vencedores e Salvando Resultados

Às 45h40, Tim prossegue para avançar vencedores para a próxima rodada. Ele explica como os vencedores são combinados com confrontos pais e por que salvar dados no momento certo é crucial.

Mais tarde, por volta das 52h10, ele demonstra uma abordagem concisa de ForEach para atualizar confrontos, explicando como é funcionalmente equivalente a um loop tradicional, mas mais compacto.

Corrigindo Bugs Introduzidos pela Refatoração

Às 58h33, Tim descobre dados incorretos no banco de dados e rastreia o problema até a lógica de chamada antes que o torneio fosse salvo. Ele explica como a refatoração às vezes expõe bugs ocultos em vez de criar novos.

Ao mover a lógica de atualização para o local correto — após a persistência — Tim resolve o problema e retesta o aplicativo.

Considerações Finais sobre Refatoração

Às 1h09:00, Tim encerra resumindo o que a refatoração alcançou nesta lição. Ele explica que a refatoração não é apenas sobre código mais limpo — é também sobre lidar com casos extremos, corrigir falhas de design e preparar para mudanças futuras.

Ele enfatiza que a refatoração é um processo contínuo e insinua que a próxima lição focará no tratamento de erros.