C# - Sete dicas para uma boa modelagem de classes

 Hoje vou apresentar algumas orientações coligidas de vários artigos que podem servir como um guia para se obter uma boa modelagem de classes na linguagem C#.

Naturalmente o artigo nem pensa em esgotar o assunto sobre o tema mas apenas contribuir com algumas orientações de forma a ajudar, principalmente quem esta iniciando com o C#, e, sente a necessidade de melhorar o seu código.

1- Uma classe ou interface deve possuir um único propósito

Uma classe ou interface deve ter uma única finalidade no sistema em que funciona.

Em geral, uma classe representa um tipo primitivo como um email, uma abstração de algum conceito de negócio, uma estrutura de dados simples ou é responsável por orquestrar a interação entre outras classes. Nunca é uma combinação desses.

Esta regra é amplamente conhecida como Princípio da Responsabilidade Única, ou SRP, um dos princípios S.O.L.I.D.

Use Padrões de projeto (Design Patterns) para comunicar a intenção de uma classe. Se você não puder atribuir um único padrão de projeto a uma classe, é provável que ele esteja fazendo mais de uma coisa e tendo assim mais de um propósito.

Se você criar uma classe representando um tipo primitivo, poderá simplificar bastante seu uso, tornando-a imutável.

2- Um construtor deve retornar um objeto útil

Não deve haver necessidade de definir propriedades adicionais antes que o objeto possa ser usado para qualquer finalidade que tenha sido projetado.

No entanto, se seu construtor precisar de mais de três parâmetros, a  sua classe pode estar com muita responsabilidade.

3- Use interfaces pequenas e bem objetivas

As interfaces devem ter um nome que explique claramente sua finalidade ou função no sistema.

Não combine muitos membros vagamente relacionados na mesma interface apenas porque estavam todos na mesma classe.

Separe os membros com base na responsabilidade desses membros, para que os chamadores precisem apenas chamar ou implementar a interface relacionada a uma tarefa específica.

Essa regra é mais conhecida como Princípio de Segregação de Interface ou ISP dos princípios SOLID.

4- Use  uma interface ao invés de uma classe abstrata para múltiplas implementações

Se você deseja expor um ponto de extensão da sua classe, exponha-o como uma interface e não como uma classe base.

Você não deseja forçar os usuários desse ponto de extensão a derivar suas implementações de uma classe base que pode ter um comportamento indesejado.

No entanto, para sua conveniência, você pode implementar uma implementação padrão (n abstrata) que pode servir como ponto de partida.

5- Use uma interface para desacoplar o código

As interfaces são um mecanismo muito eficaz para realizar o desacoplamento do código:

6- Evite usar classes estáticas

Com exceção dos contêineres dos métodos de extensão, as classes estáticas frequentemente levam a códigos mal projetados.

Elas também são muito difíceis, se não impossíveis, de serem testadas isoladamente, a menos que você esteja disposto a usar algumas ferramentas muito invasivas.

Nota: Se você realmente precisar de uma classe estática, marque-a como estática para que o compilador possa impedir membros da instância de instanciar sua classe. Isso dispensa a criação de um construtor privado explícito.

7- As classes devem ter comportamento e estado

Em geral, se você encontrar muitas classes somente de dados em sua base de código, provavelmente também terá algumas classes (estáticas) com muito comportamento.

Exceção: As únicas exceções a esta regra são as classes usadas para transferir dados por um canal de comunicação, também chamado de DTO - Data Transfer Objects, ou uma classe que agrupa vários parâmetros de um método.

"Por isso não desfalecemos; mas, ainda que o nosso homem exterior se corrompa, o interior, contudo, se renova de dia em dia."
2 Coríntios 4:16

Referências:

José Carlos Macoratti