Esta publicação está disponível em vídeo, ampliada e revisada, no canal da EximiaCo.

Com frequência, em nossas consultorias, encontramos códigos que fazem uso excessivo de tipos primitivos.

public class Employee
{
  public string Id { get; set; }
  public string Name { get; set; }
  public string Cpf { get; set; }
  public decimal Salary { get; set; }
}

No exemplo acima, usou-se string para representar pelo menos três tipos diferentes de dados. Essa abordagem “anêmica” acaba criando dificuldades, por exemplo, para implantação de validações.

public class Employee
{
  public string Id { get; set; }
  public string Name { get; set; }
  
  string _cpf;
  public string Cpf 
  { 
    get
    {
      return _cpf;
    } 
    set
    {
      // .. validation Logic
      _cpf = value;
    } 
  }
  public decimal Salary { get; set; }
}

Uma saída ingênua comum é implantar o código de validação nos Setters das propriedades. O problema, é que essa abordagem leva a duplicação de código e repetição desnecessária de testes.

public class Employee
{
  public string Id { get; set; }
  public string Name { get; set; }
  
  string _cpf;
  public string Cpf 
  { 
    get
    {
      return _cpf;
    } 
    set
    {
      if (Utils.CheckCpf(value))
      {
        throw new ArgumentException(“...”);
      }
      _cpf = value;
    } 
  }
  public decimal Salary { get; set; }
}

Como aprimoramento da solução, muitos times acabam desenvolvendo bibliotecas de uso comum (com nomes criativos como Comum, Utils, …). Entretanto, é importante observar que essas bibliotecas acabam se afastando do paradigma orientado a objetos.

Nossa recomendação é desenvolver um sistema de tipos mais rico que se afaste das primitivas.

public struct Cpf
{
  private readonly string _value; 
  
  private Cpf(string _value) { _value = value; }

  public static Cpf Parse(string value)
  {
    if (TryParse(value, out var result))
    {
      return result;
    }
    throw new ArgumentException(...);
  }

  public static bool TryParse(string value, out Cpf cpf)
  {
    //.. validation Logic 
  }

  public static implicit operator Cpf(string value)
    => Parse(value);
}

Esse tipo, por estar implementado como struct, tem custo mínimo para o runtime. Além disso, torna as implementações que o utilizam mais limpas (por não ter de explicitar a validação) e mais expressivas (pelo tipo do dado).

Observe, também, que o conversor implícito mantem esse tipo compatível com a primitiva mais próxima (no caso, string).

Seus projetos fazem uso obsessivo dos tipos primitivos? O que acha da abordagem que estamos propondo?