SOLID

Boa noite, leitores! Tudo bem? A série de artigos sobre os princípios SOLID termina hoje! Para fechar com chave de ouro, conheceremos o Dependency Inversion Principle, bastante discutido na comunidade de programadores e considerado como o mais importante entre os cinco princípios. Mas há todo um motivo para isso. Confira!

Estou aqui, leitores! Conforme esperado, o artigo de hoje aborda a letra “I” do SOLID, que corresponde ao Interface Segregation Principle, ou ISP. Assim com o LSP, este princípio também está relacionado com o conceito de abstração da orientação a objetos. Observaremos, no artigo, que abstrações genéricas podem prejudicar classes que as implementam, forçando implementações desnecessárias.

Saudações, leitores! Já temos conhecimento de que abstração, no contexto da programação, é o ato de identificar características em comum nas entidades do sistema de forma que seja possível reaproveitar comportamentos e atributos por meio de heranças. A questão é que, algumas vezes, cometemos algumas falhas no processo de abstração, levando à violação do Liskov Substitution Principle.

Olá, pessoal! Algumas vezes, a solução mais rápida para codificar uma funcionalidade ou corrigir um erro é adicionar mais um Else-If em uma estrutura já existente, não é? Bom, não sempre. Apesar de funcional, esse tipo de prática viola o segundo princípio do SOLID, chamado de Open/Closed Principle. Continue lendo o artigo para entender essa violação e como eliminá-la!

Boa noite, leitores! Como estão? Hoje iniciaremos uma nova série de apenas 5 artigos abordando os princípios SOLID. Pretendo enfatizar o objetivo de cada um deste princípios devido à sua extrema importância na arquitetura de um software. O primeiro dos princípios é a letra “S”, que corresponde ao Single Responsibility Principle. Vamos conhecê-lo?