SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.
São eles:
| Letra | Sigla | Nome | Definição |
| S | SRP | Principio da Responsabilidade Única | Uma classe deve ter um, e somente um, motivo para mudar. |
| O | OCP | Princípio Aberto-Fechado | Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo. |
| L | LSP | Princípio da Substituição de Liskov | As classes base devem ser substituíveis por suas classes derivadas. |
| I | ISP | Princípio da Segregação da Interface | Muitas interfaces específicas são melhores do que uma interface única. |
| D | DIP | Princípio da inversão da dependência | Dependa de uma abstração e não de uma implementação. |
Os princípios SOLID devem ser aplicados para se obter os benefícios da orientação a objetos, tais como:
- Seja fácil de se manter, adaptar e se ajustar às alterações de escopo;
- Seja testável e de fácil entendimento;
- Seja extensível para alterações com o menor esforço necessário;
- Que forneça o máximo de reaproveitamento;
- Que permaneça o máximo de tempo possível em utilização.
Utilizando os princípios SOLID é possível evitar problemas muito comuns:
- Dificuldade na testabilidade / criação de testes de unidade;
- Código macarrônico, sem estrutura ou padrão;
- Dificuldades de isolar funcionalidades;
- Duplicação de código, uma alteração precisa ser feita em N pontos;
- Fragilidade, o código quebra facilmente em vários pontos após alguma mudança.
Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor maduro, porém pouquíssimos profissionais preocupam-se em utilizá-los, sugiro que crie um sistema simples e utilize estes princípios para treinar, será uma experiência gratificante.
Este é apenas o artigo introdutório sobre SOLID, nos próximos abordarei cada princípio em um artigo separadamente, explicando e demonstrando com código e exemplos a proposta de cada um, continue acompanhando 😉
Referências:
Muito bom o post, mas como podemos manter esses princípios quando o cliente pede muitas alterações nas regras de negócios?
Ricardo,
É justamente para atender a constante mudança de escopo que também seguimos estes princípios, com baixo acoplamento e alta coesão podemos modificar o código com mais facilidade, segurança e garantia contra falhas não previstas.
Se tiver alguma dúvida me escreva novamente 😉
Obrigado por comentar!
Abçs!
Parabéns pelo post. Muitas vezes só o concentro não é o bastante, você deu um exemplo prático, o que permite uma maio compreensão.
Quando posto sobre os outros princípios (LID)?
Obrigado Luiz!
Estou devendo o restante dos conceitos, mas vai sair 😉
Abraços!
Parabéns pelo post, vc não teria um projeto simples de exemplo? Se possível em APs.Net.
Obrigado Diogo!
Vou produzir, tá na fila (grande fila 🙁 )
Abs
Pingback: #32: Programação Orientada a Objetos | SciCast
Prezado Eduardo,
Meus parabéns pelas suas explicações sempre didáticas e muito bem elaboradas.
Agnaldo
Pingback: Princípios SOLID, design OO e evitando dores de cabeça | O blog do Felix
Gostei da sua explicação, é uma pena que você parou de alimentas esta pagina com a continuação dos princípios.
Muito bom.
Muito bom esse artigo!
Muito bom o post, parabéns…
Gostei do bastante. Ainda vai detalhar os outros princípios ?
Parabéns e obrigado por compartilhar conhecimento
E quando recebemos dados de um webservice que traga 2 ou mais objetos, por exemplo dados da Liga que contem um atributo lista de Times.
Como mapear esse DTO para model e persistir seguindo o padrão SOLID?
Qual camada deverá ficar a chamada do WebService?
O link Design Principles and Design Patterns nas referências não está funcionando.
Boa noite, quando sair o resto da serie adiciona um link de referência!