1. Principio de inversión de dependencia
Los módulos de alto nivel no dependen de los módulos de bajo nivel, ambos deberían depender de abstracciones
La abstracción no depende de los detalles de implementación, y los detalles de implementación deberían depender de la abstracción
. Este principio es el mismo que el de la siguiente programación de interfaz en lugar de la programación de implementación. Cuando diseñamos un programa, primero debemos pensar en lo que queremos abstraer y qué capacidades debería tener. En lugar de pensar primero en cómo implementarlo, los métodos específicos y, finalmente, en función de la implementación específica que escribimos, podemos resumir cuál es la interfaz final.
2 El principio de abierto y cerrado
Abierto por extensión, cerrado por cambio
Los módulos de clase deben ser extensibles , pero no modificables .
Después de definir la interfaz, debemos garantizar la estabilidad de la capa de interfaz tanto como sea posible.
3 Principio de responsabilidad única
Una clase debe tener una sola razón para cambiarla
La dirección del cambio implica la responsabilidad de la clase.
Si hay demasiados cambios en una clase, la dificultad de mantenimiento del programa aumentará y la parte de la interfaz de la clase puede modificarse, lo que viola el segundo principio anterior.
Entre los cambios (la implementación específica utilizada, etc.), se debe aclarar el propósito específico en esta parte.
4 Principio de sustitución de Liskov
Las subclases deben poder reemplazar sus clases base .
Heredar la abstracción del tipo de expresión.
La mayoría de los patrones de diseño serían inútiles si las subclases no pudieran reemplazar a sus clases base.
5 Principios de segregación de interfaces
Los clientes no deben ser "forzados" a confiar en métodos que no usan.
Las interfaces deben ser pequeñas y completas .
Al diseñar un objeto, debemos saber claramente qué funciones debe contener el objeto, y luego crear una interfaz correspondiente y ocultar todos los demás métodos que no utilizan los clientes.
6 Preferir la composición de objetos sobre la herencia de clases
Reutilización de caja blanca: expone todo el contenido de la clase principal a la subclase.
Reutilización de la caja negra: solo exponga las partes que desea exponer, y el resto del contenido es invisible para su clase.
***La herencia de clases* suele denominarse reutilización de la caja blanca
*** La composición de objetos* suele denominarse reutilización de la caja negra
La herencia destruye la encapsulación hasta cierto punto, y el grado de acoplamiento de la subclase y la clase principal es alto
La composición de objetos solo requiere que los objetos que se componen tengan interfaces bien definidas.
7 puntos de cambio de paquete
Utilice la encapsulación para crear una capa límite entre los objetos,
lo que permite a los diseñadores modificar el otro lado del cambio sin afectar negativamente al otro lado,
logrando así un acoplamiento débil entre las capas.
8. Programe la interfaz, no la implementación
En lugar de declarar el tipo de variable como una clase concreta de un tipo particular, declárelo como una interfaz.
El programa cliente no necesita saber el tipo específico del objeto, solo necesita saber la interfaz que tiene el objeto.
Reducir las dependencias de varias partes en el sistema , para realizar el esquema de diseño de tipo de " alta cohesión y bajo acoplamiento ".