Dominando o princípio DRY: Aplicando padrões de projeto em C# para um código mais limpo.

Passos e exemplo:

1. Código inicial: A lógica para gerar o ID do funcionário estava diretamente no manipulador de eventos de clique de um botão.

   

2. Código refatorado: Tim aprimora o método, tornando-o mais flexível. Em vez de depender de elementos específicos da UI, o método agora aceita firstName e lastName como parâmetros e retorna o ID gerado. Essa alteração permite que o método seja usado em diversos contextos e elementos da interface do usuário:

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   Tim demonstra então como esse método é chamado a partir do evento de clique:

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   Ele também observa que esse método agora pode ser usado em outras partes do aplicativo, como no processamento de arquivos CSV com vários registros de funcionários, sem repetir o código.

Passos e exemplo:

1. Criando a Biblioteca de Classes:

   • Tim às (9:47), cria um novo projeto de biblioteca de classes no .NET Framework, nomeando-o DRYDemoLibrary.

   • Dentro desta biblioteca, ele define uma classe pública EmployeeProcessor e move o método GenerateEmployeeID para essa classe:

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

2. Utilizando a Biblioteca de Classes em Projetos:

   • Em seus projetos WinForms (13:18) e WPF (14:00), Tim adiciona uma referência à biblioteca de classes DRYDemoLibrary.

   • Ele então substitui o código antigo por chamadas ao método GenerateEmployeeID da biblioteca de classes:

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   • Essa abordagem elimina a redundância, pois o método agora é mantido em um único local. Tim demonstra que a mesma biblioteca de classes pode ser usada em diferentes frameworks de interface do usuário (WinForms e WPF) sem repetir o código.

3. Vantagens:

   • Consistência: Ao centralizar a lógica em uma biblioteca de classes, Tim garante que as alterações na lógica (por exemplo, correções de bugs) sejam aplicadas uniformemente em todos os projetos.

   • Manutenção reduzida: as alterações no método precisam ser feitas apenas na biblioteca de classes, evitando inconsistências e reduzindo a sobrecarga de manutenção.

Passos e exemplo:

1. Criação de uma nova solução e projeto:

   • Tim em (17:29), começa criando uma nova solução para um aplicativo de console, simulando um cenário onde você pode precisar usar a DRYDemoLibrary em um tipo diferente de projeto, como um serviço do Windows ou um aplicativo de console.

   Ele batiza o novo projeto de ConsoleUI e mostra como configurar um aplicativo de console básico.

     class Program
     {
        static void Main(string[] args)
        {
           Console.ReadLine();
        }
     }

     class Program
     {
        static void Main(string[] args)
        {
           Console.ReadLine();
        }
     }

2. Adicionando uma referência à biblioteca de classes:

   • Tim explica como adicionar uma referência à DLL DRYDemoLibrary no novo projeto. Isso envolve navegar até o arquivo DLL na pasta bin do projeto da biblioteca de classes e adicioná-lo ao aplicativo de console.

     using DRYDemoLibrary;

     using DRYDemoLibrary;

   • Depois que a referência é adicionada, Tim (19:24) usa a classe EmployeeProcessor da biblioteca para gerar um ID de funcionário com base na entrada do usuário.

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

3. Executando o aplicativo de console:

   • Tim demonstra a execução do aplicativo de console para mostrar que ele gera com sucesso o ID do funcionário usando a biblioteca. Isso confirma que o mesmo código da biblioteca de classes pode ser reutilizado em diferentes projetos.

     

4. Atualizando a DLL:

   • Tim menciona brevemente que, se a DLL for alterada, você poderá atualizá-la nos projetos que a referenciam. Ele observa que, embora este vídeo não aborde o assunto em detalhes, o uso de pacotes NuGet é uma abordagem recomendada para gerenciar e atualizar DLLs em vários projetos.

Pontos principais:

1. Criando um pacote NuGet :

   Em vez de gerenciar manualmente os arquivos DLL, Tim sugere criar um pacote NuGet para a biblioteca de classes. Isso envolve empacotar a DLL em um pacote NuGet e carregá-lo em um servidor NuGet (privado ou público).

2. Atualizando pacotes:

   • Ao usar um pacote NuGet , você pode atualizar a biblioteca em todos os projetos que a referenciam simplesmente atualizando a versão do pacote. Isso garante consistência e reduz o risco de incompatibilidades de versão ou falta de atualizações.

3. Benefícios:

   • Gerenciamento centralizado: os pacotes NuGet oferecem uma maneira centralizada de gerenciar versões e dependências de bibliotecas.

   • Facilidade de atualizações: Atualizar a biblioteca em vários projetos torna-se mais fácil e confiável.

   • Integração: O NuGet integra-se com diversas ferramentas e ambientes de desenvolvimento, simplificando o processo de gerenciamento de dependências de bibliotecas.

Configuração inicial de teste

Tim começa executando um teste unitário que atualmente falha devido a um bug na DLL. Ele destaca a importância dos testes unitários na identificação de problemas, mesmo quando o código está fora da solução principal. O código esperava uma entrada de 4 letras, mas em vez disso, Tim passou um nome de 3 letras, o que causa uma falha no arquivo DLL, mesmo que ele não esteja diretamente incluído na solução.

Refatoração de código para corrigir erros

Para resolver o problema com o tratamento de nomes próprios, Tim refatora o código. Ele explica como o princípio DRY pode ser aplicado ao desenvolvimento através da criação de um novo projeto de biblioteca de classes (23:50). Essa abordagem garante que as alterações em vários objetos possam ser feitas uma única vez e testadas com eficácia, sem a necessidade de correções repetidas.

Adicionando testes unitários

Tim introduz uma nova classe de teste chamada EmployeeProcessorTest no projeto da biblioteca de classes e configura testes unitários usando o XUnit. Ele demonstra como criar um método de teste para gerar IDs de funcionários e discute a importância de simular dependências em vez de confiar em valores reais.

Como escrever um método de teste

Tim escreve um método de teste unitário chamado GenerateEmployeeID_ShouldCalculate. Ele estabelece uma teoria com dados embutidos para testar diferentes cenários, garantindo que o método retorne os resultados esperados. Ele também explica como usar o Assert.Equal para verificar a saída.

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

Executando o teste unitário

Tim enfatiza a importância de simular dados dinâmicos, como valores de data e hora, para controlar as condições e os resultados dos testes. Ele discute o desafio de trabalhar com strings dinâmicas e como testar diferentes cenários usando valores controlados. Ele então executa o teste de unidade, mas antes disso adiciona dois pacotes NuGet necessários para executar os testes: xunit.runner.console e xunit.runner.visualstudio.

Após a execução bem-sucedida de todos os testes para um dado embutido, a saída é exibida da seguinte forma:

Agora em (31:30), Tim adicionou outro dado inline e mudou o segundo parâmetro da substring para expectedStart.Length:

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

Após executar o teste unitário novamente às 32:05, com a segunda teoria, o teste falhou:

Melhorando o código com métodos privados

Para aderir ao DRY, Tim refatora o código ainda mais criando um método privado GetPartOfName na classe EmployeeProcessor real sob a DRYDemoLibrary. Este método lida com a extração de partes de um nome, melhorando a reutilização e a legibilidade do código. Tim fez as seguintes alterações:

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

Atualizando testes unitários

Tim atualiza os testes unitários para refletir as mudanças no código, como a modificação do comprimento esperado das substrings. Ele explica como a execução desses testes ajuda a identificar rapidamente problemas e validar se o código atende aos novos requisitos. Tim adiciona novas teorias e, em seguida, executa os testes unitários para verificar se os resultados são os esperados:

Criando uma biblioteca .NET Standard

Reduzindo a repetição no desenvolvimento

Tim Corey enfatiza que, ao adotar uma biblioteca .NET Standard , você minimiza a repetição de código não apenas em sua base de código, mas também no processo de desenvolvimento. Em vez de duplicar o código em diferentes projetos específicos de plataforma, você o centraliza em uma única biblioteca que funciona em vários ambientes.

Benefícios:

• Base de código unificada : Uma única base de código para diversas plataformas reduz o esforço necessário para manter e atualizar seu código.
• Testes simplificados : Com uma biblioteca .NET Standard , você pode escrever testes unitários uma única vez e garantir que eles se apliquem a todas as plataformas suportadas.

Testes e depuração: Tim apresenta os testes unitários como uma forma de reduzir ainda mais o esforço e a repetição. Os testes automatizados verificam a correção do seu código sem a necessidade de testar manualmente cada iteração da aplicação.