Ser chamado de sólido é um elogio. A palavra carrega as noções positivas de confiabilidade e respeitabilidade. Todos nós devemos almejar nos tornar um.

Se você é um engenheiro de software ou deseja se tornar um, está com sorte porque existe um conjunto de princípios SOLID para guiar seu caminho.

SOLID é um acrônimo na profissão de engenharia de software. Ele significa:

• Princípio da Responsabilidade Única
• O princípio da caneta fechada
• L iskov Princípio da substituição
• Princípio de segregação de interface
• Princípio de inversão de dependência

Vejamos esses princípios com mais detalhes.

Responsabilidade Única

Cada classe deve ter uma única responsabilidade.

An EmailServicedeve se preocupar apenas em enviar e-mails, não em enviar e-mails e atualizar o status do pedido.

Uma Caraula deve ser apenas sobre carros, não sobre outros tipos de veículos motorizados. Se precisarmos descrever um carro elétrico, uma subclasse como ElectricCaré mais apropriada do que sobrecarregar Carcom características de carros elétricos e a gasolina.

Princípio aberto-fechado

Um módulo deve estar aberto para extensão, mas fechado para modificação

O EmailServicepode ser estendido por um RecallableEmailServiceque adiciona recurso de capacidade de recuperação ao e-mail recém-enviado.

O ElectricCaradiciona recursos elétricos sem modificar o interior do Car.

Substituição de Liskov

As subclasses devem ser substituíveis por suas classes base

No contexto do projeto orientado a objetos, uma classe ou método que aceita uma instância de uma classe base deve ser capaz de receber qualquer instância de sua subclasse.

Um OrderServicedeve ser capaz de usar qualquer instância que esteja em conformidade com a interface de EmailServicesem se preocupar que a classe real da instância seja EmailServiceela mesma ouRecallableEmailService

Um UrbanTripPlannerdeve ser capaz de usar qualquer instância de Carpara determinar uma rota sem saber se ela representa um carro elétrico ou a gasolina.

Segregação de interface

Muitas interfaces específicas do cliente são melhores do que uma interface de uso geral

Um OrderServicenão precisa recallEmail(...). Portanto, depende apenas do EmailServiceenvio de e-mails, nãoRecallableEmailService

Da mesma forma, an UrbanTripPlannernão precisa do recharge(...)método de an EletricCar. Depende apenas da interface fornecida peloCar

inversão de dependência

Depender de abstrações. Não dependa de concreções.

O mecanismo de dependência procedural começa de cima, se expande gradualmente e depende de detalhes concretos de implementação.

Na programação orientada a objetos, a dependência é invertida . A maioria das dependências deve ser baseada em abstrações. E onde existe implementação, sua relação com a abstração se inverte . Em vez de depender diretamente, a implementação agora depende da abstração.

Um OrderServicedepende da interface fornecida por EmailServicee não de sua implementação IMAP ou POP.

An UrbanTripPlannerdepende da interface fornecida por Car, não de sua implementação Tesla ou Toyota

Conclusão

Examinamos a origem do acrônimo SOLID, bem como analisamos cada um deles em detalhes com 2 casos de uso de design orientado a objetos cada.

Você pode ter seguido alguns desses princípios no passado sem saber porque são boas práticas. O encapsulamento, na minha opinião, segue o princípio Open-close .

Você também pode ter aplicado alguns deles porque é assim que as coisas são. Sintaticamente, um ElectricCarobjeto sempre pode passar por um Carparâmetro, seguindo assim o princípio de substituição de Liskov . Se você já usou Injeção de Dependência, já segue o princípio da Inversão de Dependência .

Outros princípios requerem um pouco de reflexão. O princípio da Responsabilidade Única precisa de um bom modelo OO para manter o método/classe/módulo limpo e enxuto. Você pode precisar de bom senso para determinar a profundidade da segregação enquanto segue o princípio de segregação de interface .

Referências

• Documento Princípios de Design e Padrões de Design
• Princípios do artigo OOD
• Arquitetura limpa: um guia do artesão para estrutura e design de software
• https://en.wikipedia.org/wiki/SOLID

Outros artigos desta série:

• Tornando-se um desenvolvedor SOLID
• SOLID em Ação - o Princípio da Responsabilidade Única
• SOLID em ação — o princípio aberto-fechado
• SOLID em ação — o princípio de substituição de Liskov: planejado
• SOLID em Ação — o princípio de Segregação de Interface: planejado
• SOLID em Ação — o princípio da Inversão de Dependência: planejado

Obrigada.