SOLID

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

Single Responsibility Principle (SRP)

"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)

"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)

"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)

"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)

A. "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

Referências

  1. ↑ 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.
  2. ↑ 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 
  3. ↑ Arquitetura limpa: o guia do artesão paraestrutura e design de software. [S.l.]: Alta Books. 14 de outubro de 2021 
  4. ↑ «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 
  5. ↑ 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 
  6. ↑ 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 
  7. ↑ 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 
  8. ↑ 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 
  9. ↑ 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 
Este artigo é emitido por Wikipédia. O texto é licenciado sob Creative Commons Attribution-Share Alike 4.0. Termos adicionais podem ser aplicados aos arquivos de mídia.