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 

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.