Moitas veces atópome con desenvolvedores que non escoitaron falar dos principios SOLID (nós . — Transl.) ou programación orientada a obxectos (POO), ou escoitou falar delas, pero non as use na práctica. Este artigo describe os beneficios dos principios de POO que axudan ao programador no seu traballo diario. Algúns deles son moi coñecidos, outros non tanto, polo que o artigo será útil tanto para principiantes como para programadores experimentados.
Recordámolo: para todos os lectores de Habr: un desconto de 10 rublos ao inscribirse en calquera curso de Skillbox usando o código promocional Habr.
Skillbox recomenda: Curso educativo online .
DRY (non te repitas)
Un principio bastante sinxelo, cuxa esencia é clara do nome: "Non te repitas". Para un programador, isto significa a necesidade de evitar códigos duplicados, así como a oportunidade de utilizar a abstracción no seu traballo.
Se hai dúas seccións que se repiten no código, deberían combinarse nun só método. Se un valor codificado se usa máis dunha vez, paga a pena convertelo nunha constante pública.
Isto é necesario para simplificar o código e facilitar o mantemento, que é o principal obxectivo da POO. Tampouco deberías usar excesivamente a unión, xa que o mesmo código non pasará a verificación tanto co OrderId como co SSN.
Cambios encapsulados
Os produtos de software da maioría das empresas están en constante evolución. Isto significa que hai que facer cambios no código, debe ser compatible. Podes facer a túa vida máis fácil usando a encapsulación. Isto permitirache probar e manter de forma máis eficiente a túa base de código existente. .
Se escribes en Java, entón .
Principio aberto/pechado
Este principio pódese lembrar facilmente lendo a seguinte afirmación: "As entidades de software (clases, módulos, funcións, etc.) deberían estar abertas para a súa extensión, pero pechadas para a súa modificación". Na práctica, isto significa que poden permitir que se cambie o seu comportamento sen cambiar o código fonte.
O principio é importante cando os cambios no código fonte requiren revisión do código, probas unitarias e outros procedementos. O código que segue o principio aberto/pechado non cambia cando se estende, polo que hai moitos menos problemas con el.
Aquí tes un exemplo de código que viola este principio.
Se necesitas cambiar algo nel, levará moito tempo, xa que todas as seccións do código que teñan unha conexión co fragmento desexado terán que ser cambiadas.
Por certo, a apertura-pecha é un dos principios de SOLID.
Principio de Responsabilidade Única (SRP)
Outro principio do conxunto SOLID. Afirma que "non hai máis que unha causa que provoca un cambio de clase". A clase só resolve un problema. Pode ter varios métodos, pero cada un deles só se usa para resolver un problema común. Todos os métodos e propiedades deben servir só para iso.
O valor deste principio é que afrouxa o acoplamento entre o compoñente de software individual e o código. Se engades máis dunha funcionalidade a unha clase, introduce unha relación entre as dúas funcións. Así, se cambias un deles, hai unha gran probabilidade de estragar o segundo, que está conectado ao primeiro. E isto significa aumentar os ciclos de probas para identificar todos os problemas con antelación.
Principio de inversión de dependencia (DIP)
Arriba hai un exemplo de código onde AppManager depende de EventLogWriter, que á súa vez está estreitamente ligado a AppManager. Se necesitas unha forma diferente de mostrar unha notificación, xa sexa push, SMS ou correo electrónico, debes cambiar a clase AppManager.
O problema pódese resolver usando DIP. Entón, en lugar de AppManager, solicitamos un EventLogWriter, que se introducirá usando o framework.
DIP fai posible substituír facilmente módulos individuais por outros cambiando o módulo de dependencia. Isto fai posible cambiar un módulo sen afectar aos outros.
Composición en lugar de herdanza
Hai dúas formas principais de reutilizar o código: a herdanza e a composición, que teñen as súas propias vantaxes e desvantaxes. Normalmente prefírese o segundo porque é máis flexible.
A composición dálle a posibilidade de cambiar o comportamento dunha clase en tempo de execución establecendo as súas propiedades. Ao implementar interfaces utilízase o polimorfismo, o que dá unha implementación máis flexible.
Mesmo Effective Java de Joshua Bloch aconsella escoller a composición sobre a herdanza.
Principio de substitución de Barbara Liskov (LSP)
Outro principio do conxunto de ferramentas SOLID. Establece que os subtipos deben ser substituíbles polo supertipo. É dicir, os métodos e funcións que funcionan cunha superclase deberían poder funcionar sen problemas coas súas subclases.
O LSP está asociado tanto co principio de responsabilidade única como co principio de responsabilidade compartida. Se unha clase ofrece máis funcionalidades que unha subclase, esta última non admitirá parte da funcionalidade, violando este principio.
Aquí tes un anaco de código que contradí a LSP.
O método de área (Rectángulo r) calcula a área dun rectángulo. O programa fallará despois de executar Square porque Square non é un rectángulo aquí. Segundo o principio LSP, as funcións que usan referencias a clases base deberían poder usar obxectos de clases derivadas sen instrucións adicionais.
Este principio, que é unha definición específica dun subtipo, foi proposto por Barbara Liskov nunha conferencia de 1987 titulada "Abstracción e xerarquía de datos", de aí o seu nome.
Principio de división de interfaces (ISP)
Outro principio SÓLIDO. Segundo el, non se debería implementar unha interface que non se utilice. Seguir este principio axuda a que o sistema siga sendo flexible e axeitado para a refactorización cando se realizan cambios na lóxica de funcionamento.
Na maioría das veces, esta situación ocorre cando a interface contén varias funcións á vez e o cliente só necesita unha delas.
Dado que escribir unha interface é unha tarefa difícil, cambiala despois de que se complete o traballo sen romper nada será un desafío.
A vantaxe do principio ISP en Java é que todos os métodos deben ser implementados primeiro, e só entón poden ser usados por clases. Polo tanto, o principio permite reducir o número de métodos.
Programación para a interface, non para a implementación
Todo aquí está claro polo nome. A aplicación deste principio leva á creación de código flexible que pode funcionar con calquera nova implementación da interface.
Debe usar o tipo de interface para as variables, os tipos de retorno ou o tipo de argumento do método. Un exemplo é usar SuperClass en lugar de SubClass.
É dicir:
Lista de números= getNumbers();
Pero non:
ArrayList números = getNumbers();
Aquí tes unha implementación práctica do que se comenta anteriormente.
Principio de delegación
Un exemplo común son os métodos equals() e hashCode() en Java. Cando é necesario comparar dous obxectos, esta acción delégase á clase correspondente en lugar da cliente.
A vantaxe do principio é que non hai duplicación de código e é relativamente sinxelo cambiar o comportamento. Tamén se aplica á delegación de eventos.
Todos estes principios permítenche escribir códigos máis flexibles, fermosos e fiables con alta cohesión e baixo acoplamento. Por suposto, a teoría é boa, pero para que un desenvolvedor utilice realmente os coñecementos adquiridos é necesaria a práctica. Unha vez que dominas os principios de POO, o teu seguinte paso pode ser aprender patróns de deseño para resolver problemas comúns de desenvolvemento de software.
Skillbox recomenda:
- Curso práctico .
- Curso online aplicado .
- Curso práctico de dous anos .
Fonte: www.habr.com