Los Principios de Diseño Orientado a Objetos son el núcleo de la programación orientada a objetos, pero he visto a la mayoría de los programadores de Java perseguir patrones de diseño como el patrón Singleton, el patrón Decorator o el patrón Observer , y no poner suficiente atención en el aprendizaje del análisis y diseño orientado a objetos .
Es importante aprender los conceptos básicos de la programación orientada a objetos como Abstracción , Encapsulación , Polimorfismo y Herencia . Pero, al mismo tiempo, es igualmente importante conocer los principios del diseño orientado a objetos.
Le ayudarán a crear un diseño limpio y modular, que sería fácil de probar, depurar y mantener en el futuro.
He visto regularmente a programadores y desarrolladores de Java de varios niveles de experiencia, que nunca han oído hablar de estos principios de diseño OOP y SOLID , o simplemente no saben qué beneficios ofrece un principio de diseño en particular y cómo aplicar estos principios de diseño en la codificación.
Para hacer mi parte, he anotado todos los principios importantes del diseño orientado a objetos y los he puesto aquí como referencia rápida. Estos al menos le darán una idea de qué son y qué beneficios ofrecen.
No he puesto ejemplos, solo para que el artículo sea breve, pero puede encontrar muchos ejemplos de estos principios de diseño en Internet e incluso en mi blog de Java , solo use la barra de búsqueda en la parte superior de la página.
Si no puede comprender un principio de diseño, debe intentar hacer más de un ejemplo porque a veces nos conectamos mejor con otro ejemplo o autor, pero debe comprender estos principios de diseño y aprender a usarlos en su código.
Otra cosa que puede hacer es unirse a un curso integral de diseño orientado a objetos como Principios SOLID de diseño orientado a objetos de Steve Smith en Pluralsight. Me ha ayudado mucho en mi comprensión y aplicación de estos principios.
Por cierto, he compartido algunos cursos y libros relevantes y útiles aquí y allá, tanto gratuitos como de pago, y ganaré algo de dinero si compras algo que no sea gratuito.
También son algunos de los recursos que he usado para aprender los principios de diseño SOLID y Programación en general y son buenos para aprender algunos de estos principios en profundidad.
Aunque la mejor manera de aprender cualquier principio o patrón de diseño es un ejemplo del mundo real y comprender las consecuencias de violar ese principio de diseño, el tema de este artículo es Introducción a los principios de diseño orientado a objetos para programadores de Java, que no están expuestos a él o en la fase de aprendizaje.
Personalmente, creo que cada uno de estos principios de diseño OOP y SOLID necesita un artículo para explicarlos claramente, y definitivamente intentaré hacerlo aquí, pero por ahora, prepárate para un paseo rápido en bicicleta por la ciudad de los principios de diseño :)
Nuestro primer principio de diseño orientado a objetos es DRY, como sugiere el nombre DRY (no se repita) significa no escribir código duplicado, sino usar Abstracción para abstraer cosas comunes en un solo lugar.
Si tiene un bloque de código en más de dos lugares, considere convertirlo en un método separado, o si usa un valor codificado de forma rígida más de una vez, hágalo público como constante final . El beneficio de este principio de diseño orientado a objetos está en el mantenimiento .
Es importante no abusar, la duplicación no es por código, sino por funcionalidad.
Significa que si ha utilizado un código común para validar OrderId y SSN, no significa que sean iguales o que seguirán siendo los mismos en el futuro.
Al usar un código común para dos funcionalidades o cosas diferentes, las une estrechamente para siempre y cuando su ID de pedido cambie su formato, su código de validación de SSN se romperá.
Así que tenga cuidado con tal acoplamiento y simplemente no combine nada que use el código similar pero que no esté relacionado. También puede consultar el curso Conceptos básicos de arquitectura de software y patrones de diseño en Java en Udemy para obtener más información sobre cómo escribir un buen código y las mejores prácticas a seguir al diseñar un sistema.
Solo hay una cosa que es constante en el campo del software y es "Cambiar". Por lo tanto, encapsule el código que espera o sospecha que se cambiará en el futuro.
El beneficio de este principio de diseño de programación orientada a objetos es que es fácil de probar y mantener el código encapsulado adecuado.
Si está codificando en Java, siga el principio de hacer que las variables y los métodos sean privados de forma predeterminada y aumente el acceso paso a paso, como de privado a protegido y no público .
Varios de los patrones de diseño en Java usan Encapsulación, el patrón de diseño Factory es un ejemplo de Encapsulación que encapsula el código de creación de objetos y brinda flexibilidad para introducir un nuevo producto más adelante sin impacto en el código existente.
Por cierto, si está interesado en obtener más información sobre los patrones de diseño en Java y la programación orientada a objetos, debe consultar este curso de Biblioteca de patrones de diseño Pluralsight. Es una de las mejores colecciones de patrones de diseño y consejos sobre cómo usarlos en el mundo real.
De acuerdo con este principio de diseño OOP, "las clases, los métodos o las funciones deben estar abiertos para la extensión (nueva funcionalidad) y cerrados para la modificación".
Este es otro hermoso principio de diseño SOLID, acuñado por el tío Bob en su clásico libro Clean Code , que evita que alguien cambie el código ya probado.
El beneficio clave de este principio de diseño es que el código ya probado no se toca, lo que significa que no se romperá.
Aquí hay un ejemplo de código Java que viola el Principio de programación de diseño abierto y cerrado:
En este código, GraphicEditor está estrechamente relacionado con Shape. Si necesita una nueva Shape, debe modificar el código ya probado dentro del método drawShape (Shape s), que es propenso a errores y no deseable.
Idealmente, si está agregando una nueva funcionalidad solo, su código debe probarse y ese es el objetivo del principio de diseño abierto y cerrado .
Por cierto, el principio Abierto-Cerrado es "O" del acrónimo SOLID. Si desea obtener más información sobre este principio, el curso Principios SOLID de diseño y arquitectura orientados a objetos en Udemy es uno de los mejores recursos para consultar.
El principio de responsabilidad única es otro principio de diseño SOLID y representa una "S" en el acrónimo SOLID. Según SRP, no debe haber más de una razón para que una clase cambie, o una clase siempre debe manejar una sola funcionalidad.
El beneficio clave de este principio es que reduce el acoplamiento entre el componente individual del software y el Código.
Por ejemplo, si coloca más de una funcionalidad en una clase en Java, introduce el acoplamiento entre dos funcionalidades e incluso si cambia una funcionalidad, existe la posibilidad de que rompa la funcionalidad acoplada, lo que requiere otra ronda de pruebas para evitar sorpresas en la producción. ambiente.
También puedes ver From 0 to 1: Design Patterns — 24 That Matter Course en Udemy para obtener información sobre los patrones que se basan en este principio.
No pida dependencia, se la proporcionará el marco. Esto ha sido muy bien implementado en Spring framework , uno de los framework Java más populares para escribir aplicaciones de valor real.
La belleza de este principio de diseño es que cualquier clase inyectada por el marco DI es fácil de probar con el objeto simulado y más fácil de mantener porque el código de creación de objetos está centralizado en el marco y el código del cliente no está lleno de eso.
Hay varias formas de implementar la inyección de dependencia, como usar la instrumentación de bytecode que hace algún marco AOP (programación orientada a aspectos) como AspectJ o usar proxies como se usa en Spring.
También puede consultar el curso Principios SOLID de diseño y arquitectura orientados a objetos en Udemy para obtener más información sobre este útil principio. También representa "D" en el acrónimo SÓLIDO.
Aquí hay un ejemplo del código que viola el Principio de Inversión de Dependencia o DIP en Java:
Puede ver que AppManager depende de EventLogWriter, que está estrechamente relacionado con AppManager. Si necesita usar otra forma de notificar a su cliente, como enviar notificaciones automáticas, SMS o correo electrónico, debe cambiar la clase de AppManager.
Este problema se puede resolver mediante el uso del Principio de inversión de dependencia donde, en lugar de que AppManager solicite EventLogWriter, el marco lo inyectará o proporcionará a AppManager.
Puede ver más información sobre el uso de principios SOLID para escribir mejor código: un curso intensivo en Udemy para obtener más información sobre el principio de inversión de dependencia y cómo resolver tales problemas.
Hay dos formas generales de reutilizar el código que ya ha escrito, Herencia y Composición, ambas tienen sus propias ventajas y desventajas, pero, en general, siempre debe favorecer la composición sobre la herencia, si es posible.
Algunos de ustedes pueden argumentar esto, pero descubrí que la Composición es mucho más flexible que la Herencia .
La composición permite cambiar el comportamiento de una clase en tiempo de ejecución al establecer propiedades durante el tiempo de ejecución y al usar interfaces para componer una clase, usamos polimorfismo que brinda flexibilidad para reemplazar con una mejor implementación en cualquier momento.
Incluso Efective Java de Joshua Bloch aconseja favorecer la composición sobre la herencia. Si aún no está convencido, también puede leer aquí para obtener más información sobre por qué su Composición es mejor que la Herencia para reutilizar el código y la funcionalidad.
Y, si sigues olvidando esta regla, aquí tienes una bonita caricatura para poner en tu escritorio :-)
Si está interesado en obtener más información sobre conceptos de programación orientada a objetos como composición, herencia, asociación, agregación, etc., también puede consultar el curso Programación orientada a objetos en Java en Coursera .
Es gratis para explorar y aprender, pero se le cobrará si también desea participar en ejercicios, tareas, evaluaciones y necesita Certificación para mostrar en su perfil de LinkedIn.
De acuerdo con el principio de sustitución de Liskov, los subtipos deben ser sustituibles por el supertipo, es decir, los métodos o funciones que usan el tipo de superclase deben poder trabajar con el objeto de la subclase sin ningún problema”.
LSP está estrechamente relacionado con el principio de responsabilidad única y el principio de segregación de interfaz .
Si una clase tiene más funcionalidad que una subclase, es posible que no admita parte de la funcionalidad y viole LSP.
Para seguir el principio de diseño LSP SOLID , la clase o subclase derivada debe mejorar la funcionalidad, pero no reducirla. LSP representa "L" en el acrónimo SÓLIDO.
Aquí hay un ejemplo de código que viola el principio de sustitución de Liskov en Java:
Principio de sustitución de Liskov en Java
Si tiene un área de método (Rectángulo r) que calcula el área de Rectángulo, entonces ese código se romperá cuando pase el Cuadrado porque Cuadrado no es realmente un Rectángulo.
Si está interesado en un ejemplo más real, entonces el curso Principios SOLID de diseño orientado a objetos en Pluarlsight es un buen curso para comenzar.
Por cierto, necesitaría una membresía de Pluralsight para acceder a este curso, que cuesta alrededor de $ 29 por mes o $ 299 al año (14% de descuento). Incluso si no tiene una membresía, aún puede acceder a este curso GRATIS aprovechando su prueba gratuita de 10 días sin ningún compromiso, que es una excelente manera no solo de acceder a este curso de forma gratuita, sino también de verificar el calidad de los cursos antes de unirse a Pluralsight
El principio de segregación de la interfaz establece que un cliente no debe implementar una interfaz si no la usa.
Esto sucede principalmente cuando una interfaz contiene más de una funcionalidad y el cliente solo necesita una funcionalidad y ninguna otra.
No hay duda de que el diseño de la interfaz es un trabajo complicado porque una vez que lanzas tu interfaz no puedes cambiarla sin romper toda implementación. Bueno, la función de método predeterminado o defensor de Java 8 proporciona una forma de evolución de la interfaz, pero no todos los lenguajes de programación admiten esas funciones.
Otro beneficio de este principio de diseño en Java es que la interfaz tiene la desventaja de implementar todos los métodos antes de que cualquier clase pueda usarlos, por lo que tener una sola funcionalidad significa menos métodos para implementar.
Si no obtiene el beneficio de la interfaz en la codificación, le sugiero que lea la publicación de mi blog, el uso real de una interfaz en Java para obtener más información.
Un programador siempre debe programar para la interfaz y no para la implementación , esto conducirá a un código flexible que puede funcionar con cualquier nueva implementación de la interfaz.
En palabras concretas, debe usar el tipo de interfaz en las variables, devolver los tipos de un método o el tipo de argumento de los métodos en Java, como usar el tipo SuperClass para almacenar objetos en lugar de usar SubClass.
quiero decir
Listar numeros= getNumeros();
en vez de
Números de ArrayList = getNumbers();
Esto también se ha recomendado en muchos libros de Java, incluido el libro de patrones de diseño de Java efectivo y Head First.
Aquí hay un ejemplo de codificación para la interfaz en Java:
Si está interesado en mejorar la calidad del código de su programa, también le sugiero que eche un vistazo al curso Refactoring to Design Patterns en Udemy, que lo ayudará a mejorar el diseño interno con técnicas de refactorización y patrones de diseño en C#.
No hagas todas las cosas tú solo, delégalas a la clase respectiva. El ejemplo clásico del principio de diseño de delegación es el método equals() y hashCode() en Java .
Para comparar la igualdad de dos objetos, le pedimos a la clase misma que haga la comparación en lugar de que la clase Cliente haga esa verificación.
El beneficio clave de este principio de diseño es que no hay duplicación de código y es bastante fácil modificar el comportamiento. La delegación de eventos es otro ejemplo de este principio, donde un evento se delega a los controladores para su manejo.
Todos estos principios de diseño orientado a objetos lo ayudan a escribir un código mejor y flexible al esforzarse por una alta cohesión y un bajo acoplamiento.
La teoría es el primer paso, pero lo más importante es desarrollar la capacidad de saber cuándo aplicar estos principios de diseño .
Una vez que lo domine, el siguiente paso es aprender patrones de diseño en Java, que utiliza estos patrones de diseño para resolver problemas comunes de desarrollo de aplicaciones e ingeniería de software.
Si está buscando un buen curso para comenzar, le sugiero que se una al curso From 0 to 1: Design Patterns — 24 That Matter — In Java en Udemy. Es muy completo y puede obtenerlo en solo $ 11 en sus varias ventas flash.
De todos modos, aquí hay un buen resumen de todos estos principios de diseño OOP.
Averigüe si estamos violando algún principio de diseño y comprometiendo la flexibilidad del código, pero nuevamente, como nada es perfecto en este mundo, no siempre intente resolver el problema con patrones de diseño y principios de diseño, son principalmente para proyectos de grandes empresas que tiene un ciclo de mantenimiento más largo.
La conclusión es que los programadores profesionales siempre deben esforzarse por lograr una solución, un código o un diseño altamente cohesivo y poco acoplado. Mirar el código fuente abierto de Apache y Google son algunas buenas maneras de aprender los principios de diseño de Java y OOP .
Le mostrarán cómo se deben usar los principios de diseño en la codificación y los programas Java. El kit de desarrollo de Java sigue muchos principios de diseño, como el patrón de fábrica en la clase BorderFactory, el patrón Singleton en la clase java.lang.Runtime, el patrón Decorator en varias clases de java.io.
Si está interesado en aprender principios y patrones orientados a objetos, entonces puede consultar mi otro libro favorito Head First Object-Oriented Analysis and Design , un excelente libro y probablemente el mejor material disponible en análisis y diseño orientados a objetos.
No muchos programadores conocen este libro porque a menudo está a la sombra de su primo más popular Head First Design Pattern de Eric Freeman , que trata más sobre cómo estos principios se unen para crear un patrón que puede usar directamente para resolver problemas conocidos.
Estos libros ayudan mucho a escribir mejor código, aprovechando al máximo varios principios de diseño SOLID y orientado a objetos. Por cierto, si realmente te interesan más las prácticas de codificación de Java, lee la tercera edición de Java eficaz de Joshua Bloch, una joya del tipo que escribió la API de la colección Java.
Si desea obtener más información sobre los principios de diseño de SOLID, aquí hay algunos recursos útiles que puede consultar:
Y, si le gusta este artículo, también le pueden gustar estos artículos de programación y Java : 10 cosas que los programadores de Java deben aprender en 2019 10 libros que todo programador debe leer 10 consejos para mejorar sus habilidades de programación 10 herramientas que todo desarrollador de software debe saber 5 cursos para Aprenda la arquitectura de software en profundidad 20 bibliotecas y APIS El programador de Java debe saber Los 10 principales lenguajes de programación para aprender en 2019 10 Framework y biblioteca Java y el desarrollador web debe aprender
Gracias por leer este artículo. Si encuentra útiles estos principios de diseño orientado a objetos, compártalos con sus amigos y colegas. Si tiene alguna pregunta o comentario, envíe una nota.
Por cierto, si compras alguno de mis libros o cursos recomendados, también me pagarán.
Si te gusta este artículo, considera seguirme en medium ( javinpaul ). si desea recibir una notificación por cada nueva publicación y no se olvide de seguir a javarevisited en Twitter.
PD: si realmente te apasiona la codificación y quieres mejorar tus habilidades de codificación, no hay mejores libros que Clean Code de Robert Martin y Refactoring de Martin P. Fowler . Solo ve y léelos.