Diferencias

Muestra las diferencias entre dos versiones de la página.

--- ada:howto:sicoferp:factory:solid [2023/11/07 13:28]
192.168.175.10 creado
+++ ada:howto:sicoferp:factory:solid [2023/11/07 14:54] (actual)
192.168.175.10
@@ Línea 1: / Línea 1: @@
 ====== Buenas prácticas de desarrollo de software: Principios SOLID ======
-Esta sección presenta una introducción a los 5 principios SOLID los cuales ayudan a desarrollar sotfware de calidad.
+Esta sección presenta una introducción a los 5 principios **SOLID** los cuales ayudan a desarrollar sotfware de calidad.
-Cuando se trata del diseño y desarrollo de aplicaciones, los 'Principios SOLID' son un conjunto de conceptos esenciales que debes tener en tu repertorio como fundamentos clave en la arquitectura y creación de software.
+Cuando se trata del diseño y desarrollo de aplicaciones, los '**Principios SOLID**' son un conjunto de conceptos esenciales que debes tener en tu repertorio como fundamentos clave en la arquitectura y creación de software.
-SOLID es un acrónimo creado por Michael Feathers, que se basa en los principios de la programación orientada a objetos compilados por Robert C. Martin en su artículo de 2000, titulado 'Design Principles and Design Patterns'. Estos principios sientan las bases para el desarrollo de software de alta calidad y mantenible en el mundo de la programación orientada a objetos((https://profile.es/blog/principios-solid-desarrollo-software-calidad/)).
+**SOLID** es un acrónimo creado por **Michael Feathers**, que se basa en los principios de la programación orientada a objetos compilados por **Robert C. Martin** en su artículo de 2000, titulado '**//Design Principles and Design Patterns//**'. Estos principios sientan las bases para el desarrollo de software de alta calidad y mantenible en el mundo de la programación orientada a objetos((https://profile.es/blog/principios-solid-desarrollo-software-calidad/)).
-Los 5 principios SOLID de diseño de aplicaciones de software son:
+Los 5 principios **SOLID** de diseño de aplicaciones de software son:
-  * S – Single Responsibility Principle (SRP)
+  * **S** – //Single Responsibility Principle// (SRP)
-  * O – Open/Closed Principle (OCP)
+  * **O** – //Open/Closed Principle// (OCP)
-  * L – Liskov Substitution Principle (LSP)
+  * **L** – //Liskov Substitution Principle// (LSP)
-  * I – Interface Segregation Principle (ISP)
+  * **I** – //Interface Segregation Principle// (ISP)
-  * D – Dependency Inversion Principle (DIP)
+  * **D** – //Dependency Inversion Principle// (DIP)
-===== ¿Que es Clean Code? =====
+===== S - Principio de responsabilidad única =====
-El código limpio no se basa en reglas rígidas, sino en una serie de principios que promueven la creación de un código intuitivo y fácil de modificar. En este contexto, la intuición implica que cualquier profesional de desarrollo pueda comprenderlo de inmediato. Un código que es fácilmente adaptable presenta las siguientes características:
+El Principio de Responsabilidad Única establece que una clase debe desempeñar una única función y, en consecuencia, tener un solo motivo para cambiar.
-  * El flujo de ejecución del programa sigue una lógica clara y tiene una estructura sencilla.
+Para expresar este principio en términos más técnicos: Solo debería ser posible que un cambio potencial, como alteraciones en la lógica de la base de datos o en la lógica de registro, afecte la especificación de una clase.
-  * Las relaciones entre las distintas partes del código son transparentes.
-  * La función de cada clase, función, método y variable es evidente a simple vista.
-Un código se considera fácil de modificar cuando es flexible y extensible, lo que facilita la corrección de posibles errores. Por estas razones, el código limpio resulta sencillo de mantener y exhibe las siguientes cualidades:
+En otras palabras, si una clase representa una entidad o un contenedor de datos, como una clase "Libro" o "Estudiante," y contiene campos relacionados con esa entidad, solo debería requerir modificaciones cuando el modelo de datos subyacente cambie.
-  * Las clases y los métodos son concisos y, siempre que sea posible, tienen una única función bien definida.
+Es fundamental adherirse al principio de responsabilidad única por varias razones. En primer lugar, en proyectos donde múltiples equipos pueden trabajar en la misma clase por diversas razones, no seguir este principio podría resultar en módulos incompatibles.
-  * Las clases y los métodos son predecibles, operan de acuerdo a las expectativas y se acceden a través de API (interfaces) claramente documentadas.
-  * El código ha sido sometido a pruebas unitarias.
-Las ventajas de este enfoque de programación son evidentes: el código limpio se vuelve independiente del desarrollador que lo creó. En esencia, cualquier programador puede trabajar con él, lo que evita los problemas asociados con el código heredado. Además, el mantenimiento del software se simplifica, ya que los errores son más fáciles de identificar y corregir((https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/clean-code-que-es-el-codigo-limpio/)).
+En segundo lugar, facilita el seguimiento de versiones. Por ejemplo, si observamos cambios en un archivo en las confirmaciones de GitHub y seguimos el Principio de Responsabilidad Única, podemos inferir que esos cambios están relacionados con el almacenamiento o cuestiones vinculadas a la base de datos.
-===== 7 Reglas principales del Clean Code =====
+Además, este enfoque también reduce los conflictos de fusión. Los conflictos suelen surgir cuando diferentes equipos modifican el mismo archivo, pero al adherirse al Principio de Responsabilidad Única, los conflictos se minimizan, ya que los archivos solo tienen un motivo para cambiar, lo que simplifica la resolución de conflictos.
-==== 1. La importancia de los nombres ====
+===== O - Principio de apertura y cierre =====
-La elección de nombres desempeña un papel fundamental en la comprensión de un código, ya sea para variables, funciones, parámetros, clases o métodos. Al seleccionar un nombre, es esencial considerar dos aspectos clave:
+El principio de apertura y cierre establece que las clases deben ser abiertas a la extensión y cerradas a la modificación.
-Debe ser preciso y expresar la idea central de manera directa.
+La 'modificación' se refiere a cambiar el código de una clase existente, mientras que la 'extensión' implica agregar nuevas funcionalidades. En resumen, este principio promueve la idea de que debemos poder introducir nuevas funciones sin necesidad de alterar el código preexistente de una clase. Esto se debe a que cada vez que modificamos el código existente, corremos el riesgo de introducir posibles errores. Por lo tanto, es aconsejable evitar tocar el código de producción que ya ha sido probado y es confiable en su mayoría.
-No temas usar nombres largos si ello es necesario para representar con claridad la función o propósito.
-==== 2. Regla del boy scout ====
+Puede preguntarse cómo es posible agregar nueva funcionalidad sin modificar la clase original. Por lo general, esto se logra mediante el uso de interfaces y clases abstractas, que permiten extender y agregar nuevas capacidades a las clases existentes sin cambiar su implementación subyacente.
-Esta regla se basa en la idea de que, al salir de un área de acampada, debes dejarla más ordenada de lo que la encontraste. En el ámbito de la programación, esto se traduce en dejar el código más limpio de lo que estaba antes de editarlo.
-==== 3. Sé el autor auténtico del código ====
+===== L - Principio de sustitución de Liskov =====
-El código es una narrativa, y los programadores son los autores de esta historia. Para estructurar un código limpio, es fundamental crear funciones simples, claras y concisas. Dos reglas orientadoras son:
+El Principio de Sustitución de Liskov establece que las subclases deben ser intercambiables por sus clases base.
-  * Mantén las funciones pequeñas.
+En otras palabras, si la clase B es una subclase de la clase A, deberíamos poder utilizar un objeto de la clase B en lugar de un objeto de la clase A en cualquier contexto, como un método que espera un objeto de la clase A, sin experimentar resultados inesperados.
-  * Y, si es posible, aún más pequeñas.
-Es importante no confundir "**nombre**" con "**función**". Como se mencionó en el primer principio, los nombres largos no son un problema, pero las funciones deben mantenerse breves.
+Este comportamiento es el esperado ya que cuando aplicamos la herencia, suponemos que la clase hija hereda todas las características de la clase madre. La clase hija puede extender el comportamiento, pero nunca debe reducirlo.
-==== 4. DRY (No te repitas) ====
+Cuando una clase no cumple con este principio, puede llevar a errores inesperados y difíciles de detectar en el código.
-Este principio, acuñado en el libro "//**The Pragmatic Programmer**//," se aplica a diversas áreas de desarrollo, como:
-  * Bases de datos
+===== I - Principio de segregación de interfaces =====
-  * Pruebas
+La segregación implica la separación de elementos, y el Principio de Segregación de Interfaces se enfoca en la separación de interfaces.
-  * Documentación
-  * Codificación
-**DRY** defiende que cada elemento del conocimiento del sistema debe ser único y exento de ambigüedades, evitando así la duplicación de funcionalidades.
-==== 5. Comentar con moderación ====
+Este principio defiende que es preferible tener múltiples interfaces específicas para los clientes en lugar de una única interfaz general. La idea es no obligar a los clientes a implementar funciones que no necesitan ni utilizarán.
-Los comentarios en el código deben ser utilizados con moderación y solo cuando sean realmente necesarios. Según la perspectiva de **Uncle Bob**, los comentarios pueden inducir a error, ya que suelen quedar obsoletos al modificarse el código. Por lo tanto, si se opta por comentar, debe ser de manera esencial y revisada conjuntamente con la versión del código.
-==== 6. Manejo de errores ====
+===== D - Principio de inversión de dependencia =====
-El autor **Michael Feathers** destacó la importancia de tratar adecuadamente las excepciones en el desarrollo web. Los programadores son responsables de garantizar que el código siga funcionando incluso cuando surgen problemas. Tratar las excepciones de manera correcta es un aspecto clave en este proceso.
+El principio de inversión de dependencia establece que nuestras clases deben depender de interfaces o clases abstractas en lugar de depender de clases y funciones concretas.
-==== 7. Pruebas limpias ====
+En su artículo de 2000, **Robert C. Martin** resume este principio de la siguiente manera:
-La realización de pruebas es una etapa crucial en la programación, y solo un código que ha pasado pruebas limpias puede considerarse verdaderamente limpio. Para ello, se deben cumplir ciertas reglas:
-  * **Rápido**: Las pruebas deben ejecutarse rápidamente y en cualquier momento.
+> "//Si el Principio de Apertura y Cierre establece el objetivo de la arquitectura orientada a objetos, el Principio de Inversión de Dependencia establece el mecanismo principal//".
-  * **Independiente**: Las pruebas deben ser independientes para evitar efectos en cascada en caso de fallo.
-  * **Repetible**: Deben ser repetibles en diferentes entornos.
+Estos dos principios están estrechamente relacionados, y ya hemos aplicado este patrón al discutir el Principio de Apertura y Cierre.
-  * **Autovalidación**: Las pruebas bien escritas devuelven respuestas claras (verdadero o falso) para evitar subjetividades en los errores.
-  * **Puntual**: Las pruebas deben ser escritas antes del código mismo, siguiendo estrictamente el criterio de puntualidad.
+El objetivo es que nuestras clases estén abiertas a la extensión, por lo que reestructuramos nuestras dependencias para que dependan de interfaces en lugar de depender de clases y funciones concretas.
-El **Clean Code** es un concepto arraigado que resuelve de manera eficiente uno de los principales desafíos que enfrentan muchos proyectos de desarrollo de sistemas: el mantenimiento((https://www.hostgator.mx/blog/clean-code-codigo-limpio/)).
 [[ada:howto:sicoferp:factory:goodsoftwaredevelopmentpractices|←Volver atras]]

Wiki

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página