Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

• S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

  

• O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
• L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
• I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
• D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉