Muitas vezes encontro desenvolvedores que nunca ouviram falar dos princípios SOLID (nós . — Trad.) ou programação orientada a objetos (OOP), ou já ouviu falar deles, mas não os utiliza na prática. Este artigo descreve os benefícios dos princípios OOP que auxiliam o desenvolvedor em seu trabalho diário. Alguns deles são bem conhecidos, outros nem tanto, então o artigo será útil tanto para iniciantes quanto para programadores experientes.
Lembramos: para todos os leitores Habr - um desconto de 10 rublos ao se inscrever em qualquer curso Skillbox usando o código promocional Habr.
A Skillbox recomenda: Curso educacional on-line .
SECA (não se repita)
Um princípio bastante simples, cuja essência fica clara no nome: “Não se repita”. Para um programador, isso significa a necessidade de evitar código duplicado, bem como a oportunidade de utilizar abstração em seu trabalho.
Se houver duas seções repetidas no código, 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 sua manutenção, que é o principal objetivo da OOP. Você também não deve abusar da união, pois o mesmo código não passará na verificação com OrderId e SSN.
Encapsulando Mudanças
Os produtos de software da maioria das empresas estão em constante evolução. Isso significa que mudanças precisam ser feitas no código, ele precisa ser suportado. Você pode tornar sua vida mais fácil usando encapsulamento. Isso permitirá que você teste e mantenha com mais eficiência sua base de código existente. .
Se você escreve em Java, então .
Princípio aberto/fechado
Este princípio pode ser facilmente lembrado lendo a seguinte afirmação: “As entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação”. Na prática, isso significa que eles podem permitir que seu comportamento seja alterado sem alterar o código-fonte.
O princípio é importante quando alterações no código-fonte exigem revisão de código, testes unitários e outros procedimentos. O código que segue o princípio aberto/fechado não muda quando estendido, portanto há muito menos problemas com ele.
Aqui está um exemplo de código que viola esse princípio.
Se precisar alterar alguma coisa nele, isso levará muito tempo, pois todas as seções do código que possuem conexão com o fragmento desejado deverão ser alteradas.
Aliás, abertura-fechamento é um dos princípios do SOLID.
Princípio de Responsabilidade Única (SRP)
Outro princípio do conjunto SOLID. Afirma que “há apenas uma causa que causa uma mudança de classe”. A aula 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 para isso.
O valor deste princípio é que ele afrouxa o acoplamento entre o componente de software individual e o código. Se você adicionar mais de uma funcionalidade a uma classe, isso introduzirá um relacionamento entre as duas funções. Assim, se você trocar um deles, há grandes chances de estragar o segundo, que está ligado ao primeiro. E isso significa aumentar os ciclos de testes para identificar antecipadamente todos os problemas.
Princípio de Inversão de Dependência (DIP)
Acima está um exemplo de código em que o AppManager depende do EventLogWriter, que por sua vez está intimamente ligado ao AppManager. Se você precisar de uma forma diferente de mostrar uma notificação, seja push, SMS ou e-mail, será necessário alterar a classe AppManager.
O problema pode ser resolvido usando DIP. Assim, ao invés do AppManager, solicitamos um EventLogWriter, que será inserido utilizando o framework.
O DIP torna possível substituir facilmente módulos individuais por outros, alterando o módulo de dependência. Isto torna possível alterar um módulo sem afetar os outros.
Composição em vez de herança
Existem duas maneiras principais de reutilizar código: herança e composição, ambas com vantagens e desvantagens. Normalmente o segundo é preferido porque é mais flexível.
A composição oferece a capacidade de alterar o comportamento de uma classe em tempo de execução, definindo suas propriedades. Na implementação de interfaces, é utilizado o polimorfismo, o que proporciona uma implementação mais flexível.
Even Effective Java, de Joshua Bloch, aconselha a escolha da composição em vez da herança.
Princípio da Substituição de Barbara Liskov (LSP)
Outro princípio do kit de ferramentas SOLID. Ele afirma que os subtipos devem ser substituíveis pelo supertipo. Ou seja, métodos e funções que funcionam com uma superclasse devem poder funcionar sem problemas com suas subclasses.
O LSP está associado tanto ao princípio da responsabilidade única como ao princípio da responsabilidade partilhada. Se uma classe fornece mais funcionalidades do que uma subclasse, então esta última não suportará algumas das funcionalidades, violando este princípio.
Aqui está um trecho de código que contradiz o LSP.
O método area(Rectangle r) calcula a área de um retângulo. O programa irá travar após executar Square porque Square não é um retângulo aqui. De acordo com o princípio LSP, funções que utilizam referências a classes base devem ser capazes de utilizar 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 numa conferência de 1987 intitulada “Abstração e Hierarquia de Dados”, daí o seu nome.
Princípio de Separação de Interface (ISP)
Outro princípio SÓLIDO. Segundo ele, uma interface que não é utilizada não deve ser implementada. Seguir este princípio ajuda o sistema a permanecer flexível e adequado para refatoração quando são feitas alterações na lógica operacional.
Na maioria das vezes, essa situação ocorre quando a interface contém várias funções ao mesmo tempo e o cliente precisa de apenas uma delas.
Como escrever uma interface é uma tarefa difícil, alterá-la após a conclusão do trabalho sem quebrar nada será um desafio.
A vantagem do princípio ISP em Java é que todos os métodos devem ser implementados primeiro e só então podem ser usados pelas classes. Portanto, o princípio permite reduzir o número de métodos.
Programação para a interface, não para a implementação
Tudo aqui fica claro no título. A aplicação deste princípio leva à criação de um código flexível que pode funcionar com qualquer nova implementação da interface.
Você deve usar o tipo de interface para variáveis, tipos de retorno ou o tipo de argumento do método. Um exemplo é usar SuperClass em vez de SubClass.
Isto É:
Lista de números= getNumbers();
E não:
ArrayList números = getNumbers();
Aqui está uma implementação prática do que foi discutido acima.
princípio de delegação
Um exemplo comum são os métodos equals() e hashCode() em Java. Quando é necessário comparar dois objetos, esta ação é delegada à classe correspondente ao invés da classe cliente.
A vantagem do princípio é que não há duplicação de código e é relativamente simples alterar o comportamento. Também se aplica à delegação de eventos.
Todos esses princípios permitem escrever códigos mais flexíveis, bonitos e confiáveis, com alta coesão e baixo acoplamento. Claro que a teoria é boa, mas para que um desenvolvedor possa realmente utilizar o conhecimento adquirido é necessária prática. Depois de dominar os princípios de OOP, sua próxima etapa poderá ser aprender padrões de design para resolver problemas comuns de desenvolvimento de software.
A Skillbox recomenda:
- curso prático .
- Curso on-line aplicado .
- Curso prático de dois anos .
Fonte: habr.com