Es muy difícil hacer que el software sea muy flexible y fácil de mantener. La estructura del software flexible es compleja y el mantenimiento es difícil. Hay ganancias y pérdidas, y la clave está en cómo manejar la relación entre ambas para que las ganancias superen las pérdidas. El diseño y desarrollo de software debe seguir los siguientes seis principios: 1. Nombre completo de OCP: "Principio abierto-cerrado" Descripción del principio abierto-cerrado: Abierto para expansión, cerrado para modificación. Ventajas: un sistema diseñado según los principios de OCP reduce el acoplamiento entre varias partes del programa y su adaptabilidad, flexibilidad y estabilidad son relativamente buenas. Cuando es necesario agregar nuevas funciones a un sistema de software existente, no es necesario modificar la capa de abstracción que es la base del sistema. Solo es necesario agregar nuevos módulos sobre la base original para realizar las funciones agregadas. El nuevo módulo tiene muy poco o ningún impacto en el módulo original, por lo que no es necesario volver a probar el módulo original. Cómo implementar el principio "abierto-cerrado" En el diseño orientado a objetos, lo que no se permite cambiar es la capa de abstracción del sistema, pero lo que se permite ampliar es la capa de implementación del sistema. En otras palabras, defina una capa de abstracción de establecer y olvidar que permita implementar la mayor cantidad de comportamiento posible en la capa de implementación. La clave para resolver problemas reside en la abstracción, que es la primera esencia central del diseño orientado a objetos. La abstracción significa esencialmente resumir la esencia de algo. La abstracción nos permite capturar las cosas más importantes y pensar en un nivel superior. Reduce la complejidad del pensamiento y no tenemos que pensar en tantas cosas al mismo tiempo. En otras palabras, encapsulamos la esencia de las cosas y no podemos ver ningún detalle. En la programación orientada a objetos, a través de clases e interfaces abstractas, las características de las clases concretas se designan como capas abstractas, que son relativamente estables y no necesitan ser modificadas, satisfaciendo así la "cercanía a la modificación" mientras que las clases concretas se derivan de lo abstracto; las clases pueden cambiar el comportamiento del sistema, satisfaciendo así la "apertura a la extensión". Al ampliar una entidad, no es necesario cambiar el código fuente o el código binario del software. La clave es la abstracción. 2. El nombre completo de LSP: "Principio de sustitución de Liskov". El principio de sustitución de Richter explica que las subclases deben poder reemplazar sus clases base. Una entidad de software que utiliza una clase base no cambia el comportamiento del programa cuando reemplaza la clase base con una subclase que hereda de la clase base. Las entidades de software no notan la diferencia entre los objetos de clase base y los objetos de subclase. Ventajas: es fácil realizar el intercambio de varias subclases bajo la misma clase principal y el cliente no puede detectarlo. 3.DIP nombre completo: "Principio de inversión de dependencia" Descripción del principio de inversión de dependencia: Confíe en la abstracción, no en la concreción. Los clientes confían en el acoplamiento abstracto. Las abstracciones no deberían depender de los detalles, los detalles deberían depender de las abstracciones del programa para las interfaces, no de las implementaciones. Ventajas: Al utilizar las dependencias creadas por la programación de procedimientos tradicional, la estrategia depende de los detalles, lo cual es malo porque la estrategia se verá afectada por los cambios en los detalles. El principio de inversión de dependencia hace que los detalles y las estrategias dependan de abstracciones, y la estabilidad de la abstracción determina la estabilidad del sistema. ¿Cómo hacer la inversión de dependencia? El acoplamiento abstracto es la clave del principio de inversión de dependencia. Las relaciones de acoplamiento abstractas siempre involucran clases concretas que heredan de clases abstractas, y es necesario garantizar que cualquier referencia a la clase base pueda cambiarse a una referencia a su subclase, por lo que el principio de sustitución de Liskov es la base del principio de inversión de dependencia. El acoplamiento a niveles de abstracción, si bien es flexible, también introduce una complejidad adicional. Si la posibilidad de cambios en la clase concreta es pequeña, entonces los beneficios del acoplamiento abstracto son limitados y es mejor utilizar el acoplamiento concreto. Capas: todas las arquitecturas orientadas a objetos bien estructuradas tienen jerarquías bien definidas, cada una de las cuales proporciona un conjunto cohesivo de servicios al mundo exterior a través de interfaces bien definidas y controladas. Dependencia de abstracciones: se recomienda no depender de clases concretas, es decir, todas las dependencias de un programa deben terminar en clases o interfaces abstractas. En la medida de lo posible: 1. Ninguna variable debe contener un puntero o referencia a una clase concreta. 2. Ninguna clase debe derivarse de una clase concreta. 3. Ningún método anulará los métodos ya implementados en su clase base. 4. El nombre completo del "Principio de segregación de interfaces" es "Principio de segregación de interfaces", que establece que es mejor utilizar múltiples interfaces para funciones especializadas que utilizar una interfaz general.
Desde la perspectiva de la clase de cliente: la dependencia de una clase de otra clase debe basarse en una interfaz mínima. Una interfaz demasiado inflada contamina la interfaz y no debería obligar a los clientes a confiar en métodos que no utilizan. Ventajas: Evitará que la presión de modificación del sistema de software se transfiera a otros objetos cuando se amplíe su funcionalidad. ¿Cómo implementar el principio de separación de interfaces? 1. Utilice la delegación para separar interfaces. 2. Utilice herencia múltiple para separar interfaces. 5. Nombre completo de CARP o CRP: "Principio de reutilización compuesta/agregación" CARP compuesta/agregación o "Principio de reutilización compuesta": si algunas funciones de un nuevo objeto se han implementado en otro objeto creado, debes intentar usar el otro. funcionalidad proporcionada por el objeto y hacerlo parte del nuevo objeto en lugar de recrearlo usted mismo. Los nuevos objetos se crean delegando funcionalidad a otros objetos. Los nuevos objetos reutilizan la funcionalidad existente delegando funcionalidad a estos objetos. En resumen, intente utilizar composición/agregación en lugar de herencia. Ventajas 1) La única forma en que un objeto nuevo puede acceder a un objeto constituyente es a través de la interfaz del objeto constituyente. 2) Este tipo de reutilización es la reutilización de caja negra porque el nuevo objeto no puede ver los detalles internos que lo componen. 3) Esta reutilización admite la encapsulación. 4) Esta reutilización requiere menos dependencias. 5) Cada nueva clase puede centrarse en una tarea. 6) Esta reutilización puede ser dinámica en tiempo de ejecución, el nuevo objeto puede hacer referencia dinámicamente al objeto componente creado con él y el objeto puede hacer referencia dinámicamente a objetos del mismo tipo que el objeto componente. Desventajas: habrá más objetos que deberán administrarse en el sistema. El nombre completo de LOD o LKP: "Ley de Demeter" o "Principio de conocimiento mínimo": los objetos deben estar relacionados en la menor cantidad posible de formas para evitar relaciones inextricables. Cómo implementar la Ley de Demeter La intención principal de la Ley de Demeter es controlar la sobrecarga de información. Al aplicar esta ley en el diseño de sistemas, se debe prestar atención a los siguientes puntos: 1) Al dividir clases, se deben crear clases débilmente acopladas. Cuanto más débil sea el acoplamiento entre clases, más propicio será la reutilización. 2) En el diseño de la estructura de clases, cada clase debe minimizar los derechos de acceso de sus miembros. Una clase no debe exponer sus propias propiedades, sino que debe proporcionar métodos para obtener y asignar valores para que el mundo exterior pueda acceder indirectamente a sus propiedades. 3) En el diseño de clases, siempre que sea posible, una clase debe diseñarse para que sea una clase inmutable. 4) Entre las referencias a otros objetos, se deben reducir al mínimo las referencias de una clase a otros objetos.
También existe el Principio de Responsabilidad Única:
SRP - Principio de Responsabilidad Única: Para una clase, solo debe centrarse en hacer una cosa, y solo una causa hace que cambie. . A través de la responsabilidad podemos entenderla como una función, es decir, el diseño de esta clase debe tener una sola función, no dos o más. También puede entenderse como una referencia al motivo del cambio. Cuando descubra que hay dos cambios que requieren que modifiquemos esta clase, entonces debería considerar revocar esta clase. Debido a que las responsabilidades son el eje del cambio, cuando los requisitos cambian, este cambio reflejará cambios en las responsabilidades de clase. Notas sobre el uso de SRP: 1. Una clase razonable debe tener solo una razón para el cambio, es decir, una única responsabilidad.
2 No es prudente aplicar SRP u otros principios cuando no hay señales de cambio. ;
3. Una vez que los requisitos realmente cambien, se deben aplicar principios como SRP para refactorizar el código;
4. El uso del desarrollo basado en pruebas nos obligará a separar lo indispensable. componentes antes de que el diseño se vuelva maloliente;
5. Si las pruebas no pueden forzar la separación del código irrazonable, entonces debemos separar el código irrazonable antes de que el diseño se vuelva maloliente;
6. las pruebas no pueden forzar la separación del código irrazonable, entonces debemos separar el código irrazonable antes de que el diseño huela mal.
5. Si las pruebas no pueden obligarnos a separar responsabilidades y el olor a rigidez y vulnerabilidades se vuelve fuerte, entonces el código debe refactorizarse utilizando las ventajas de Facade o Proxy:
1: Eliminar el acoplamiento y reducir la rigidez del código causada por cambios en los requisitos.