SOLID — Single Responsability Principle

Quando começamos a nos preocupar com a qualidade do nosso código, ou se estamos implementando de uma melhor maneira algo em nosso projeto, se houve falar muito dos princípios SOLID, mas o que é esse principio, de onde vem? O que ele é?

Então, SOLID é um acrônimo para:

[S]ingle Responsibility Principle (Princípio da Responsabilidade Única) [O]pen/Closed Principle (Princípio do Aberto/Fechado)
[L]iskov Substitution Principle (Princípio da Substituição de Liskov) [I]nterface Segregation Principle (Princípio da Segregação de Interfaces) [D]ependency Inversion Principle (Princípio da Inversão de Dependências)

Mas o que é tudo isso? Bem, lá em meados de quando usávamos monitor CRT 1024x768 ou até 960x540, o nosso amado Robert C. Martin ou tio Bob para os chegados, lançou um artigo catalogando esses princípios pois ele acredita que são cinco princípios da programação orientada a objetos e design de código para um bom código. Porem quem criou o acrônimo foi o autor Michel Feathers.

Dado a apresentação do SOLID hoje irei abordar o primeiro principio o S.

Single Responsability Principle (Princípio da Responsabilidade Única)

Esse principio ele prega que cada classe deve ser responsável por uma única parte da funcionalidade fornecida pelo software.

A class should have one, and only one, reason to change.

Esse principio foi desenvolvido para diminuir a complexidade do código, porem como qualquer coisa na vida, preciso deixar advertido que, apesar do SOLID ser ótimo para o código, ele não tem a necessidade de se aplicado por inteiro, pois se for seguir a risca, o exagero tende a tornar mais complexo o código do que ajudar, por isso sempre analise o caso.

O porquê:

Imagine que você vai fazer um sistema bem simples e pequeno que não de mais que 100 ~ 200 linhas de código, faça uma meia dúzia ou até uma dúzia de métodos bem feitos e você estará bem sem dor de cabeça ou problema. Porem agora imagine que você esta em um projeto grande, cheio de classes, métodos que só de ver os arquivos você já fica meio perdido, agora imagina esse programa que tende a crescer e se modificar com o tempo, vai ficando mais complicado, só que ai aparece uma demanda para você fazer uma modificação em uma classe e nisso você abre essa classe, e depara com pelo menos uns 20 métodos dentro dela, fica aquele arquivo quilométrico que cansa só de ler e ainda se perde no meio das classes.

Se não bastasse, como você tem que fazer uma modificação em um método dessa classe, por ter vários métodos , o que te garante que o que você vai ajustar sem querer pode modificar algo que de algum outro método dentro dessa classe? Se em determinado momento você sente que está se tornando difícil focar em aspectos específicos de um programa, lembre-se do princípio da responsabilidade única e verifique se já não é hora de dividir algumas classes em partes.

Como funciona:

Abaixo irei mostrar uma classe, e nela da para ver que tem vários métodos ( o arquivo original estava beirando as 200 linhas),dependendo do que você for fazer tem o risco de você alterar a classe ou sem querer alterar algo que pode quebrar algum método dela, fora que esse código fica muito grande para conseguir ler e interpretar de um jeito mais fácil, dado isso como faríamos para arrumar essa classe?

Tem vários meios e isso DEPENDE de como a sua equipe organiza seus arquivos ou o projeto está, porem eu, isso é uma opinião própria, gosto de organizar da seguinte maneira:

• Crio uma pasta chamada PaymentConvert.
• Dentro dessa pasta eu crio um ARQUIVO para cada Service, com o nome bem descritivo (Um bom exemplo de nome seguindo os padrões do Clean Code, é o primeiro service ali convertPaymentOutPutToPayment, você lê e sabe o que o service faz)
• E dentro de cada service crio um método chamado execute() e implemento o service.

Pronto! Uma classe, um método, legível, fácil de dar manutenção, e não tem chance de quebrar outro método sem querer.

“Ai! Mas vou criar muitos arquivos assim!”

Não vejo problema, se for para manter o código legível, de fácil manutenção não tem problema!

Porem ai entramos em um dilema, então quer dizer que tenho que separar os métodos de TODAS as minhas classes ? Lembra o que falei lá em cima sem exageros? Tem horas que não é viável fazer isso um bom exemplo é quando uma classe implementa uma interface, não tem como você separar os métodos (até tem mas fica complicado depois) um exemplo é quando você esta fazendo uma classe repository que implementa uma Interface, não tem o por que você abstrair mais o código, pois caso você mude o repositório vai ter que trocar o código ou criar os códigos de TODOS os arquivos que você criou do repository, por isso eu sigo uma regra minha:

“Implementou uma Interface, não tem necessidade de separar”

Então pessoal, por hoje é só, espero que tenha deixado de um jeito simples para entender o principio, agora só resta aguardar os próximos artigos dos princípios SOLIDS!