Frequentemente, encontro desenvolvedores que não ouviram falar dos princípios do SOLID (
falamos sobre eles em detalhes aqui . - Transl.) Ou de programação orientada a objetos (OOP), ou ouvimos, mas não os usa na prática. Este artigo descreve os benefícios dos princípios de POO que ajudam um desenvolvedor em seu trabalho diário. Alguns deles são bem conhecidos, outros não, muito bem; portanto, o artigo será útil para iniciantes e programadores experientes.
Lembramos que: para todos os leitores de "Habr" - um desconto de 10.000 rublos ao se inscrever em qualquer curso Skillbox usando o código promocional "Habr".
A Skillbox recomenda: O Curso de Educação Online para Desenvolvedores Java .
SECA (não se repita)
Um princípio bastante simples, cuja essência é clara no título: "Não repita". Para o programador, isso significa a necessidade de evitar código duplicado, bem como a capacidade de usar abstração no trabalho.
Se o código tiver duas seções repetidas, elas deverão ser combinadas em um método. Se um valor codificado for usado mais de uma vez, vale a pena convertê-lo em uma constante pública.
Isso é necessário para simplificar o código e facilitar o suporte, que é a principal tarefa do OOP. Combinar a união também não vale a pena, porque o mesmo código não passa na verificação com o OrderId e o SSN.
Encapsulamento da mudança
Os produtos de software da maioria das empresas estão em constante evolução. Portanto, você precisa fazer alterações no código, ele precisa ser suportado. Você pode simplificar sua vida com encapsulamento. Isso permitirá testes e manutenção mais eficientes da base de código existente.
Aqui está um exemplo .
Se você escreve em Java,
por padrão, atribua métodos e variáveis particulares .
O princípio da abertura / proximidade
Este princípio pode ser facilmente lembrado lendo a seguinte declaração: "Entidades de software (classes, módulos, funções, etc.) devem estar abertas para expansão, mas fechadas para mudança". Na prática, isso significa que eles podem permitir que você altere o comportamento deles sem alterar o código fonte.
O princípio é importante quando alterações no código fonte requerem revisão, teste de unidade e outros procedimentos. O código que obedece ao princípio de abertura / proximidade não muda durante a expansão; portanto, há muito menos problemas com ele.
Aqui está um exemplo de código que viola esse princípio.
Se você precisar alterar algo, isso levará muito tempo, pois você precisará alterar todas as seções do código que tenham uma conexão com o fragmento desejado.
A propósito, abertura-fechamento é um dos princípios do SOLID.
Princípio de responsabilidade única (SRP)
Outro princípio do conjunto SOLID. Ele afirma que "existe apenas uma razão que leva a uma mudança de classe". Uma classe resolve apenas um problema. Pode ter vários métodos, mas cada um deles é usado apenas para resolver um problema comum. Todos os métodos e propriedades devem servir apenas isso.
O valor desse princípio é que ele enfraquece a conexão entre o componente de software individual e o código. Se você adicionar mais de uma funcionalidade a uma classe, isso introduzirá uma conexão entre as duas funções. Portanto, se você alterar um deles, há uma grande chance de estragar o segundo, associado ao primeiro. E isso significa um aumento nos ciclos de teste para identificar todos os problemas com antecedência.
Princípio da inversão de dependência (DIP)
O exemplo acima é um código de exemplo em que o AppManager depende de um EventLogWriter, que por sua vez está intimamente relacionado ao AppManager. Se você precisar de outra maneira de mostrar uma notificação, seja por push, SMS ou email, precisará alterar a classe AppManager.
O problema pode ser resolvido usando o DIP. Portanto, em vez do AppManager, solicitamos um EventLogWriter, que será introduzido usando a estrutura.
O DIP permite substituir facilmente módulos individuais por outros, alterando o módulo de dependência. Isso torna possível alterar um módulo sem afetar o restante.
Composição em vez de herança
Existem duas maneiras principais de reutilizar o código - isso é herança e composição, e cada uma tem suas próprias vantagens e desvantagens. O segundo é geralmente preferido porque é mais flexível.
A composição permite alterar o comportamento de uma classe no tempo de execução, definindo suas propriedades. Ao implementar interfaces, o polimorfismo é usado, o que proporciona uma implementação mais flexível.
Até o “Java efetivo”, de Joshua Bloch, recomenda dar preferência à composição em vez de herança.
Princípio de substituição de Barbara Lisk (LSP)
Outro princípio do kit de ferramentas do SOLID. Ele afirma que os subtipos devem ser substituíveis por um supertipo. Ou seja, métodos e funções que trabalham com uma superclasse devem poder trabalhar com suas subclasses sem problemas.
O LSP está conectado tanto ao princípio da responsabilidade única quanto ao princípio da divisão da responsabilidade. Se uma classe fornecer mais funcionalidade do que uma subclasse, ela não suportará algumas funções, violando esse princípio.
Aqui está um pedaço de código que contradiz o LSP.
O método area (Rectangle r) calcula a área do retângulo. O programa falhará após a execução do Square, pois o Square não é um retângulo aqui. De acordo com o princípio LSP, funções que usam referências a classes base devem poder usar objetos de classes derivadas sem instruções adicionais.
Este princípio, que é uma definição específica de um subtipo, foi proposto por Barbara Liskov em 1987 em uma conferência no relatório principal intitulada "Abstração e hierarquia de dados" - daí o nome.
Princípio de separação de interface (ISP)
Outro princípio do SOLID. Segundo ele, uma interface que não é usada não deve ser implementada. Seguir esse princípio ajuda o sistema a permanecer flexível e adequado para refatoração ao fazer alterações na lógica do trabalho.
Na maioria das vezes, essa situação ocorre quando a interface contém várias funcionalidades ao mesmo tempo e o cliente precisa de apenas uma delas.
Como escrever uma interface é uma tarefa difícil, após a conclusão do trabalho, alterá-la sem interromper nada será um problema.
A vantagem do princípio ISP em Java é que todos os métodos devem ser implementados primeiro, e somente então eles podem ser usados pelas classes. Portanto, o princípio torna possível reduzir o número de métodos.
Programação para uma interface, não uma implementação
Tudo aqui é claro a partir do nome. A aplicação desse princípio leva à criação de código flexível que pode funcionar com qualquer nova implementação de interface.
Use o tipo de interface para variáveis, tipos de retorno ou o tipo do argumento do método. Um exemplo é o uso da SuperClasse, não da SubClasse.
Isto é:
Números de lista = getNumbers ();E não:
Números ArrayList = getNumbers ();Aqui está uma implementação prática do que foi dito acima.
Princípio da delegação
Um exemplo comum são os métodos equals () e hashCode () em Java. Quando é necessário comparar dois objetos, essa ação é delegada na classe correspondente em vez do cliente.
Uma vantagem do princípio é a ausência de duplicação de código e uma mudança relativamente simples de comportamento. Também é aplicável à delegação de eventos.
Todos esses princípios permitem escrever código mais flexível, bonito e confiável, com alta conectividade e baixa velocidade. Obviamente, a teoria é boa, mas para o desenvolvedor realmente começar a usar o conhecimento adquirido, é necessária prática. O próximo passo após dominar os princípios da OOP pode ser o estudo de padrões de design para resolver problemas comuns de desenvolvimento de software.
A Skillbox recomenda: