Classes Utilitárias em Projetos de Software

Uma classe helper ou utilitária é uma estrutura amplamente utilizada nos frameworks de empresas de software. Seu uso, no entanto, divide opiniões. De um lado, esse conceito é considerado um bad smell por especialistas em Orientação a Objetos. De outro, profissionais experientes confirmam a necessidade de implementá-las em projetos de sistemas, mesmo sabendo que a prática viola alguns princípios de design de software.

Quando você pensa na palavra utilitários, isso remete a coisas úteis que auxiliam tarefas comuns do dia a dia.

Mas como isso se aplica no contexto de software?

Uma classe utilitária é essencialmente uma classe estática, sem atributos, sem encapsulação de estado e que contém apenas métodos estáticos. Este tipo de classe fornece funcionalidades comuns que são usadas nas aplicações. Se você usa algumas operações com frequência em seu programa, convém criar uma classe que te ajude a manipulá-las em um único lugar, para evitar a repetição de código.

Uma situação comum onde você pode escrever uma classe utilitária é para organizar métodos que realizam operações em documentos XML: leitura e escrita, validação, serialização, etc.

A nomenclatura para este tipo de classe é o sufixo Utils ao nome da classe, como, por exemplo: IOUtils, StringUtils, FileUtils, etc. Ainda, você pode encontrar esta estrutura em alguns textos como helper class. É a mesma coisa.

Um Guia para Criar uma Classe Utilitária

  1. Veja se você pode criar métodos de extensão como uma alternativa (incluir um comportamento a uma classe existente);
  2. Crie uma classe estática sem atributos/propriedades;
  3. Crie métodos estáticos
  4. Crie uma classe para testar os métodos da classe utilitária

Nesse artigo vamos criar uma classe que valida datas em strings.

Crie uma classe estática com o nome DateValidatorUtils:

 public static class DateValidatorUtils
{
}

O método ValidateDate devolve um valor booleano indicando se a data recebida é válida ou não. Ele chama o método IsDateTime, que por sua vez executa o método TryParse da classe DateTime que faz a validação de fato.

/// <summary>
/// Valida uma data string no formato dd/mm/aaaa HH:MM:SS:MMM
/// </summary>
/// <param name="date"></param>
/// <returns></returns>
public static bool ValidateDate(string date)
{
    return IsDateTime(date) ? true : false;
}

private static bool IsDateTime(string date)
{
    DateTime value;

    return DateTime.TryParse(date, out value) ? true : false;
}

O outro método, ValidateDateTime, valida uma data string em horas, minutos e segundos e devolve um objeto DateTime. O método String.Split é chamado para separar os dígitos antes e depois do ‘:’.

/// <summary>
/// Valida uma data string em horas, minutos e segundos e devolve um objeto DateTime
/// </summary>
/// <param name="date"></param>
/// <returns></returns>
public static DateTime ValidateDateTime(string date)
{
    string[] arrDate = date.Split(':');

    try
    {
        var hour = Convert.ToInt32(arrDate[0]);
        var min = Convert.ToInt32(arrDate[1]);
        var sec = Convert.ToInt32(arrDate[2]);

        DateTime objDate = new DateTime(hour, min, sec);

        if (!IsDateTime(date))
            throw new Exception("Erro na validação");

        return objDate;
    }
    catch (Exception)
    {
        throw;
    }
}

Quebra de Paradigma

Por ser um repositório genérico de métodos que atuam sobre valores – e não sobre objetos – isso pode ser considerado uma quebra de paradigma, se você estiver desenvolvendo uma solução orientada a objetos. Também se soma ao fato de a classe utilitária usar o modificador static, que não permite a instanciação de objetos.

Uma classe utilitária é dada como uma má prática de Orientação a Objetos pois “isola” algoritmos procedurais, já que não há a utilização de objetos.

Classes Utilitárias x Princípios de Design

Uma classe utilitária viola ou não se aplica a alguns princípios de design de software:

SRP – Single Responsibility Principle

Uma classe deve ter uma única responsabilidade. Esse princípio é violado quando em uma classe temos métodos que correspondem a responsabilidades distintas. Se você modelar sua classe utilitária para atender a uma única responsabilidade, então, nesse caso esse princípio não será violado.

Como saber se sua classe viola o SRP? Monte uma frase explicando o que ela faz. Se sua frase tiver um “e” ou um “ou” significa que ela faz várias coisas.

LSP – Liskov Substitution Principle

Este princípio afirma que classes derivadas (subclasses) devem ser substituíveis pelas suas classes base. No caso de classes utilitárias, porém, não existe relação de herança. Então, esse princípio não se aplica a classes utilitárias.

ISP – Interface Segregation Principle

O Princípio da Segregação de Interfaces exige que as classes que implementam interfaces não dependem de métodos que não usam. Mais um princípio que não se aplica a classes utilitárias, pois esse tipo de classe não implementa nenhuma interface.

OCP – Open-Closed Principle

Esse princípio diz que uma classe deve ser aberta para extensão e fechada para modificação. Isso significa que para adicionar um novo comportamento você deve depender de abstrações ao invés de alterar o código existente.

Como você não pode estender uma classe utilitária, pois todos os seus métodos são estáticos, além de que ela é uma classe que não cria objetos, então esse princípio é violado.

DIP – Dependency Inversion Principle

O Princípio da Inversão de Dependência indica que seu código deve depender de abstrações, e não de implementações concretas. Ou seja, módulos de alto nível não devem depender de módulos de baixo nível, mas sim de abstrações; e abstrações não devem depender de detalhes, mas sim detalhes devem depender de abstrações.

Aqui, uma abstração define o comportamento que será implementado, então para isso considere uma interface ou classe abstrata.

Uma classe utilitária não é aplicável a este princípio porque ela não implementa uma interface ou estende uma classe base.

 

Apesar de as classes utilitárias não serem consideradas uma boa prática dentro do paradigma de Orientação a Objetos, no âmbito profissional eu acredito que esse conceito seja um respaldo para implementações do dia a dia de um desenvolvedor, por isso muitas empresas adotam-nas em seus frameworks. Não é errado criar classes utilitárias em seus projetos, desde que você tenha um propósito claro em mente.

Anúncios

6 Respostas para “Classes Utilitárias em Projetos de Software

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s