Na programação orientada a objetos, o termo SOLID é um acrônimo mnemônico para cinco princípios destinados facilitar a compreensão, o desenvolvimento e a manutenção do código-fonte de programas de computador. Embora os princípios tenham sido formulados para a aplicação na programação orientada a objetos, eles também formam um núcleo filosófico para metodologias como o desenvolvimento ágil de software e o desenvolvimento adaptativo de software. Palestra ministrada na Gotham Ruby Conference 2009.
Os princípios foram formulados e apresentados pelo engenheiro de software e instrutor Robert C. Martin em um artigo sobre deterioração de software chamado, em tradução livre, Princípios de Projeto e Padrões de Projeto.
Originalmente chamados de Principles of Object Oriented Class Design (Princípios de Projeto de Classes Orientadas a Objetos) na publicação original, os cinco princípios foram posteriormente chamados pelo acrônimo SOLID por Michael Feathers em 2004, ao reorganizá-los e coletar a primeira letra da sigla de cada um.
Princípios Single Responsibility Principle (SRP) "Nunca deve haver mais que uma razão para uma classe mudar."
Importância do princípio da responsabilidade única:
Manutenibilidade: Classes que possuem uma única responsabilidade bem definida são mais fáceis de entender e modificar. Testabilidade: Se torna mais fácil escrever testes unitários quando a classe possui uma única função específica. Flexibilidade: Mudanças em classes com responsabilidades únicas tendem a impactar menos outras partes do sistema.
Open Closed Principle (OCP) "Entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação."
Importância do princípio do aberto/fechado:
Extensibilidade: Novas funcionalidades podem ser introduzidas sem modificar código existente. Estabilidade: Reduz o risco de introduzir bugs ao realizar mudanças. Flexibilidade: Torna mais fácil a adaptação a alterações de requisitos.
Liskov Substitution Principle (LSP) "Funções que recebem ponteiros ou referências de classes base devem conseguir operar com objetos de classes derivadas de forma transparente."
Importância do princípio da substituição de Liskov:
Polimorfismo: Permite o uso de comportamento polimórfico, tornando o código mais flexível e reutilizável. Confiabilidade: Garante que classes derivadas mantenham o contrato definido pelas classes bases. Previsibilidade: Garante que substituir um objeto de classe base por um objeto de classe derivada não resultará em erros.
Interface Segregation Principle (ISP) "Clientes não devem ser forçados a depender de interfaces que eles não usam."
Importância do princípio da segregação de interface:
Desacoplamento: Reduz a dependência entre classes, tornando o código mais modular e sustentável. Flexibilidade: Permite implementações mais específicas e direcionadas das interfaces, adaptando o código às necessidades de cada contexto. Evita dependências desnecessárias: Permite que clientes não exponham métodos que eles não implementam.
Dependency Inversion Principle (DIP) A. "Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações."
B. "Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações."
Importância do princípio da inversão de dependência:
Baixo acoplamento: Reduz a dependência entre módulos, tornando o código mais flexível e fácil de testar. Flexibilidade: Permite mudanças em implementações sem afetar clientes. Manutenibilidade: Torna o código mais fácil de entender e modificar.
Ver também Reutilização de código Herança (programação orientada a objetos) Don't repeat yourself GRASP (object-oriented design) Princípio KISS YAGNI
Categoria:Programação orientada a objetos Categoria:Desenho de software