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.[1]
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.[2]
Originalmente chamados de Principles of Object Oriented Class Design (Princípios de Projeto de Classes Orientadas a Objetos) na publicação original,[2] 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.[3]
Princípios
editarSingle Responsibility Principle (SRP)
editar"Nunca deve haver mais que uma razão para uma classe mudar."[4]
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.[5]
Open Closed Principle (OCP)
editar"Entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação."[6]
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.[6]
Liskov Substitution Principle (LSP)
editar"Funções que recebem ponteiros ou referências de classes base devem conseguir operar com objetos de classes derivadas de forma transparente."[7]
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.[7]
Interface Segregation Principle (ISP)
editar"Clientes não devem ser forçados a depender de interfaces que eles não usam."[8]
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.[8]
Dependency Inversion Principle (DIP)
editarA. "Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações."[9] B. "Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações."[9]
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.[9]
Ver também
editar- Reutilização de código
- Herança (programação orientada a objetos)
- Don't repeat yourself
- GRASP (object-oriented design)
- Princípio KISS
- YAGNI
Referências
- ↑ Metz, Sandi (30 de maio de 2009). «SOLID Object-Oriented Design». YouTube. Consultado em 22 de outubro de 2025. Cópia arquivada em 21 de dezembro de 2021 Palestra ministrada na Gotham Ruby Conference 2009.
- ↑ a b Martin, Robert C. (2000). «Design Principles and Design Patterns» (PDF). Object Mentor. Consultado em 22 de outubro de 2025. Cópia arquivada (PDF) em 22 de outubro de 2025
- ↑ Arquitetura limpa: o guia do artesão paraestrutura e design de software. [S.l.]: Alta Books. 14 de outubro de 2021
- ↑ «SRP: The Single Responsibility Principle» (PDF). Object Mentor (em inglês). Consultado em 23 de outubro de 2025. Cópia arquivada (PDF) em 2 de fevereiro de 2025
- ↑ Martin, Robert C.; Martin, Robert C. (2003). Agile software development: principles, patterns, and practices. Col: Alan Apt series. Upper Saddle River, NJ: Prentice Hall/Pearson Education. p. 95
- ↑ a b «The Open-Closed Principle» (PDF). Object Mentor (em inglês). Consultado em 23 de outubro de 2025. Cópia arquivada (PDF) em 5 de setembro de 2015
- ↑ a b «The Liskov Substitution Principle» (PDF). Object Mentor (em inglês). Consultado em 23 de outubro de 2025. Cópia arquivada (PDF) em 5 de setembro de 2015
- ↑ a b «The Interface Segregation Principle» (PDF). Object Mentor (em inglês). Consultado em 23 de outubro de 2025. Cópia arquivada (PDF) em 5 de setembro de 2015
- ↑ a b c «The Dependency Inversion Principle» (PDF). Object Mentor (em inglês). Consultado em 23 de outubro de 2025. Cópia arquivada (PDF) em 5 de setembro de 2015
