Muy a menudo me encuentro con desarrolladores que no han oído hablar de los principios de SOLID (nosotros . - Transl.) o programación orientada a objetos (OOP), o escuchado, pero no los use en la práctica. Este artículo describe los beneficios de los principios de programación orientada a objetos que ayudan al desarrollador en su trabajo diario. Algunos de ellos son muy conocidos, otros no tanto, por lo que el artículo será útil tanto para principiantes como para programadores ya experimentados.
Recordamos: para todos los lectores de "Habr": un descuento de 10 rublos al inscribirse en cualquier curso de Skillbox utilizando el código promocional "Habr".
Skillbox recomienda: Curso educativo en línea .
SECO (No te repitas)
Un principio bastante simple, cuya esencia se desprende del nombre: "No te repitas". Para un programador, esto significa la necesidad de evitar código duplicado, así como la capacidad de utilizar la abstracción en el trabajo.
Si hay dos secciones repetidas en el código, deben combinarse en un solo método. Si un valor codificado se utiliza más de una vez, vale la pena convertirlo en una constante pública.
Esto es necesario para simplificar el código y facilitar su mantenimiento, que es la tarea principal de la programación orientada a objetos. Tampoco debes abusar de la unión, ya que el mismo código no pasará la verificación tanto con OrderId como con SSN.
Cambiar encapsulación
Los productos de software de la mayoría de las empresas están en constante evolución. Esto significa que es necesario cambiar el código, es necesario mantenerlo. Puedes hacer tu vida más fácil con la encapsulación. Esto le permitirá probar y mantener de forma más eficaz su base de código existente. .
Si estás escribiendo en Java entonces .
El principio de apertura/cercanía.
Este principio se puede recordar fácilmente leyendo la siguiente afirmación: "Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas a la extensión, pero cerradas a la modificación". En la práctica, esto significa que pueden permitir que se cambie su comportamiento sin cambiar el código fuente.
El principio es importante cuando los cambios en el código fuente requieren revisiones, pruebas unitarias y otros procedimientos. El código que obedece al principio abierto/cerrado no cambia cuando se extiende, por lo que hay muchos menos problemas con él.
A continuación se muestra un ejemplo de código que viola este principio.
Si necesita cambiar algo en él, llevará mucho tiempo, porque tendrá que cambiar todas las partes del código que tienen conexión con el fragmento deseado.
Por cierto, la apertura-cierre es uno de los principios de SOLID.
Principio de responsabilidad única (PRS)
Otro principio del conjunto SOLID. Dice que "sólo hay una razón que lleva a un cambio de clase". La clase tiene una sola tarea. Puede tener varios métodos, pero cada uno de ellos se utiliza únicamente para resolver un problema común. Todos los métodos y propiedades deberían servir solo para esto.
El valor de este principio es que afloja el vínculo entre una sola pieza de software y el código. Agregar más de una funcionalidad a una clase introduce una relación entre las dos funciones. Así, si cambias uno de ellos, existe una gran posibilidad de estropear el segundo, relacionado con el primero. Y esto significa aumentar los ciclos de prueba para identificar todos los problemas de antemano.
Principio de inversión de dependencia (DIP)
Lo anterior es un ejemplo de código en el que AppManager depende de EventLogWriter, que a su vez está estrechamente relacionado con AppManager. Si necesita una forma diferente de mostrar la notificación, ya sea push, SMS o correo electrónico, debe cambiar la clase AppManager.
El problema se puede solucionar con DIP. Entonces, en lugar de AppManager, solicitamos un EventLogWriter, que se inyectará utilizando el marco.
DIP permite reemplazar fácilmente módulos individuales por otros cambiando el módulo de dependencia. Esto hace posible cambiar un módulo sin afectar a los demás.
Composición en lugar de herencia
Las dos formas principales de reutilizar código son la herencia y la composición, cada una con sus propias ventajas y desventajas. Generalmente se prefiere el segundo porque es más flexible.
La composición le brinda la posibilidad de cambiar el comportamiento de una clase en tiempo de ejecución estableciendo sus propiedades. Al implementar interfaces, se utiliza polimorfismo, lo que proporciona una implementación más flexible.
Incluso el "Java efectivo" Joshua Bloch aconseja favorecer la composición sobre la herencia.
Principio de sustitución de Barbara Liskov (LSP)
Otro principio del conjunto de herramientas SOLID. Afirma que los subtipos deben ser reemplazables por un supertipo. Es decir, los métodos y funciones que funcionan con una superclase deberían poder funcionar sin problemas con sus subclases.
LSP está relacionado tanto con el principio de responsabilidad única como con el principio de separación de responsabilidades. Si una clase proporciona más funcionalidad que una subclase, entonces esta última no admitirá alguna funcionalidad, violando este principio.
Aquí hay un fragmento de código que contradice LSP.
El método area(Rectangle r) calcula el área de un Rectángulo. El programa se bloqueará después de ejecutar Square, ya que aquí Square no es un rectángulo. Según el principio LSP, las funciones que utilizan referencias a clases base deberían poder utilizar objetos de clases derivadas sin instrucciones adicionales.
Este principio, que es una definición específica de un subtipo, fue propuesto por Barbara Liskov en una conferencia magistral de 1987 llamada "Abstracción y jerarquía de datos", de ahí su nombre.
Principio de separación de interfaz (ISP)
Otro principio SÓLIDO. Según él, una interfaz que no se utiliza no debería implementarse. Seguir este principio ayuda a que el sistema siga siendo flexible y refactorizable al realizar cambios en la lógica de trabajo.
La mayoría de las veces, esta situación ocurre cuando la interfaz contiene varias funcionalidades a la vez y el cliente solo necesita una de ellas.
Dado que escribir una interfaz es una tarea compleja, una vez completado el trabajo, cambiarla sin romper nada será un problema.
La ventaja del principio ISP en Java es que todos los métodos deben implementarse primero y solo entonces las clases pueden utilizarlos. Por tanto, el principio permite reducir el número de métodos.
Programación para una interfaz, no para una implementación
Aquí todo queda claro por el nombre. La aplicación de este principio conduce a un código flexible que puede funcionar con cualquier implementación de interfaz nueva.
Debe utilizar un tipo de interfaz para variables, tipos de retorno o el tipo de argumento de un método. Un ejemplo es utilizar SuperClass en lugar de SubClass.
Es decir:
Números de lista= getNumbers();
Y no
Números de ArrayList = getNumbers();
A continuación se muestra una implementación práctica de lo dicho anteriormente.
Principio de delegación
Un ejemplo común son los métodos equals() y hashCode() en Java. Cuando es necesario comparar dos objetos, esta acción se delega a la clase apropiada en lugar de a la clase de cliente.
La ventaja del principio es que no hay duplicación de código y es relativamente fácil cambiar el comportamiento. También se aplica a la delegación de eventos.
Todos estos principios le permiten escribir código más flexible, hermoso y confiable con alta cohesión y bajo acoplamiento. Por supuesto, la teoría es buena, pero para que un desarrollador realmente comience a utilizar los conocimientos adquiridos, se necesita práctica. El siguiente paso después de dominar los principios de la programación orientada a objetos puede ser el estudio de patrones de diseño para resolver problemas comunes de desarrollo de software.
Skillbox recomienda:
- Curso práctico .
- Curso en línea aplicado .
- Curso práctico de dos años. .
Fuente: habr.com