SOLID é um acrônimo para os cinco princípios de projeto de software desenvolvidos por Robert C. Martin, conhecidos como "os princípios SOLID de programação orientada a objetos".
Introdução
Single Responsibility Principle (SRP) - Um módulo ou classe deve ter uma única responsabilidade, ou seja, deve ser responsável por uma única parte da funcionalidade do sistema. Isso significa que cada classe ou módulo deve ser projetado para realizar uma tarefa específica e não deve ter responsabilidades adicionais. Isso garante que o código seja mais fácil de manter e entender, pois cada classe tem uma única razão para mudar.
Open-Closed Principle (OCP) - Um módulo ou classe deve estar aberto para extensão, mas fechado para modificação. Isso significa que ele deve ser projetado de forma a permitir a adição de novas funcionalidades sem alterar o código existente. Isso pode ser alcançado através da herança ou da implementação de interfaces, permitindo que novas classes possam ser adicionadas sem afetar as classes existentes. Isso garante que o código seja escalável e fácil de manter.
Liskov Substitution Principle (LSP) - As classes derivadas devem ser substituíveis pelas classes base. Isso significa que se uma classe pode ser usada no lugar de outra, elas devem ter uma relação de herança. Isso garante que as classes derivadas possam ser usadas de forma intercambiável com as classes base, sem afetar o comportamento do sistema.
Interface Segregation Principle (ISP) - Não se deve forçar clientes a implementar interfaces que eles não usam. As interfaces devem ser específicas para as necessidades de cada cliente. Isso significa que as interfaces devem ser divididas em interfaces menores e mais específicas, ao invés de uma única interface grande, para garantir que os clientes não sejam forçados a implementar métodos que eles não precisam.
Dependency Inversion Principle (DIP) - Os módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações. Isso significa que o código deve ser projetado de forma a depender de interfaces ou abstrações, em vez de classes concretas. Isso garante que as classes de alto nível não sejam dependentes de classes de baixo nível, permitindo que as classes de alto nível não sejam dependentes de classes de baixo nível, permitindo que as classes de alto nível possam ser facilmente testadas e reutilizadas sem afetar as classes de baixo nível. Isso também permite que as classes de baixo nível possam ser facilmente substituídas ou atualizadas sem afetar as classes de alto nível. Isso ajuda a manter o código escalável e fácil de manter.
No próximo artigo vamos colocar a mão na massa e visualizar tudo que foi escrito até aqui no código
Top comments (0)