Você já ouviu falar em Princípios de Design, no que se trata de programação?

Bem, quando iniciei minha carreira como programador em C#, eventualmente algumas dúvidas me assolavam. Dúvidas como “O código que desenvolvi está correto? É assim que profissionais fariam esse código? Se não, como eles fariam então?”

O fato é que não existe uma resposta correta sobre como você deve fazer o seu código. Mas existem diversos princípios de design que sugerem como você pode fazer o seu código, para que este seja mais legível, organizado e sustentável a longo prazo.

Neste artigo, falaremos um pouco de um conjunto de princípios de programação chamado S.O.L.I.D, criado por Robert C. Martin, também conhecido como Uncle Bob.

Cada letra da palavra SOLID indica um dos princípios de design:
S = Single Responsibility Principle
O = Open/Closed Principle
L = Liskov Substitution Principle
I = Interface Segregation Principle
D = Dependency Inversion Principle

Cada um destes princípios tem seu papel fundamental no desenvolvimento de softwares. Porém, iremos aqui explorar apenas um dos princípios, o qual eu considero como de extrema importância tanto para programadores iniciantes quanto para programadores experientes.

Single Responsibility Principle (SRP)

Este princípio sugere que: uma classe deve ter apenas uma razão para mudar.
É também possível interpretar de outra maneira: uma classe deve ter apenas uma razão para falhar.

Suponhamos uma classe chamada “Calculadora” que é responsável por duas funcionalidades:
1 – Realizar operações aritméticas tais como Soma e Multiplicação
2 – Desenhar a User Interface (UI) da calculadora, na tela do usuário

Segue uma imagem meramente ilustrativa.

Na medida que forem adicionadas novas operações aritméticas à calculadora, existe a chance de que, por um erro de operações aritméticas, de repente a UI pare de ser mostrada ao usuário. Da mesma maneira, na medida que melhoramos a UI da calculadora, existe a chance de algum método das operações aritméticas deixar de funcionar.

Isso pode acontecer por diversos fatores, como por exemplo o fato de haverem variáveis globais que são alteradas tanto pelas funções aritméticas, quanto pelo método que desenha a UI para o usuário. São duas funcionalidades totalmente diferentes, que alteram os mesmos conjuntos de dados, pois tais funcionalidades se encontram na mesma classe e, portanto, têm acesso a exatamente às mesmas variáveis e métodos. Dessa maneira, podem acabar quebrando uma à outra.

Vale ressaltar que este foi um exemplo bem básico de código que pode dar bastante dor de cabeça. Durante a minha carreira, já vi casos bem piores. Eu mesmo já desenvolvi uma classe que possuía cerca de 4 funcionalidades. Ao modificar uma destas funcionalidades, as chances das outras funcionalidades quebrarem eram grandes. Ao corrigir o que quer que estivesse quebrado, as chances de mais uma das funcionalidades quebrar também era grande.

Dessa maneira perdia-se bastante tempo de desenvolvimento pelo fato de que modificar uma funcionalidade naquela classe envolvia tantas outras coisas. Eu gastava mais tempo pensando em como manter a paz entre as funcionalidades, do que de fato implementando o código novo para que o projeto pudesse seguir em frente.

O mais indicado aqui então é separar as funcionalidades em múltiplas classes e encapsular os dados e métodos com bastante cuidado. Por exemplo, dados cruciais para as operações aritméticas devem ser privados e a sua leitura só deve ser possível através de Properties.

Segue uma imagem ilustrativa sobre como poderíamos separar melhor as funcionalidades da classe Calculadora.

Dessa maneira, o código de exibição da UI da calculadora só tem um motivo para falhar e o código está mais seguro. O mesmo serve para o código de operações aritméticas.

Que tal tirar um tempo para refatorar aquela sua classe que dá muito trabalho por ser responsável por tantas funcionalidades do seu projeto? Refatorando essas classes malignas, você pode ganhar muito mais tempo do que se você for continuar com essa classe gerando tanto problema.

Busque aprender mais sobre princípios de programação. Sugiro você continuar o estudo de S.O.L.I.D indo para a letra a letra D: Dependency Inversion Principle.