Em Object Oriented Programming (OOP), classes utilitárias são de evitar. O mesmo se pode dizer de métodos estáticos.
Um bom design OOP deve procurar que cada objeto represente uma entidade real, uma parte do todo que é o software, com uma responsabilidade bem definida e uma vida útil determinada pelo exercício dessa responsabilidade, e não mais do que isso. Uma classe utilitária ou um método estático acabam por ir contra o exercício desse objetivo.
No entanto, podemos separar o nosso design em duas partes distintas: domínio do problema e infraestrutura.
Por domínio, refiro-me ao conjunto de código relativo especificamente ao projeto em que estamos a trabalhar. User Interface, regras de negócio, etc. são da alçada do domínio. Já na infraestrutura, podemos ter classes ou métodos de apoio, que não representem claramente uma entidade, mas que não estão relacionadas com o projeto em si, mas sim com características específicas da linguagem de programação que estivermos a usar.
Neste artigo iremos ver um exemplo de uma classe de infraestrutura: a classe Using.
[...]
category-label- 
