Principio de responsabilidad única:
Un objeto debe contener solo una única responsabilidad, y esa responsabilidad está completamente encapsulada en una clase.
Principio de responsabilidad única (SRP): cada objeto debe tener una responsabilidad única, y esa responsabilidad debe estar completamente encapsulada por la clase.
En lo que respecta a una clase,
nunca debe haber más de una razón para que una clase cambie.
El principio de responsabilidad única analiza
cuantas más responsabilidades asume una clase (desde módulos hasta métodos), es menos probable que sea reutilizada.
Cuando una responsabilidad cambia, puede afectar el funcionamiento de otras responsabilidades
para separar estas responsabilidades. Encapsular diferentes responsabilidades en diferentes clases.
Encapsular diferentes razones para cambios en diferentes clases.
El principio de responsabilidad única es la guía para lograr una alta cohesión y un bajo acoplamiento.
Principio de apertura y cierre:
Las entidades de software deben estar abiertas para la extensión y cerradas para la modificación.
Principio abierto-cerrado (OCP): las entidades de software deben estar abiertas para la extensión, pero cerradas para la modificación.
Análisis del principio de apertura y
cierre El principio de apertura y cierre fue propuesto por Bertrand Meyer en 1988.
En la definición del principio de apertura y cierre, una entidad de software puede ser un módulo de software, una estructura parcial compuesta de múltiples clases, o una clase independiente. El principio de apertura y cierre
se refiere al software Las entidades deben intentar expandirse sin modificar el código original.
La abstracción es la clave del principio de apertura y cierre.
Capa de abstracción relativamente estable + capa de hormigón flexible
. Principio de encapsulación de Variación (EVP): encuentre los factores de las variables del sistema y encapsúlelos
Principio de sustitución de Liskov:
Todos los lugares que hacen referencia a la clase base deben poder utilizar objetos de sus subclases de forma transparente.
Principio de sustitución de Liskov (LSP): las funciones que usan punteros o referencias a clases base deben poder usar objetos de clases derivadas sin saberlo.
Análisis del principio de sustitución de Liskov Si
un objeto de clase base se reemplaza por su objeto de subclase en el software, el programa no producirá ningún error ni excepción, y viceversa. Si una entidad de software usa un objeto de subclase, es posible que no pueda usar el objeto de clase base.
Intente usar el tipo de clase base para definir el objeto en el programa y luego determine su tipo de subclase en tiempo de ejecución.
Principio de inversión de dependencia:
Los módulos de alto nivel no deben depender de los módulos de bajo nivel, todos deben depender de abstracciones. Las abstracciones no deberían depender de los detalles, los detalles deberían depender de las abstracciones.
Principio de inversión de dependencia (DIP): los módulos de alto nivel no deben depender de los módulos de bajo nivel, ambos deben depender de abstracciones Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones Programa contra interfaces, no contra implementaciones Programa para una interfaz
,
no una implementación.
Análisis del principio de inversión de dependencia
Al pasar parámetros en código de programa o en relaciones de asociación, trate de referirse a clases de capas abstractas de alto nivel, es decir, use interfaces y clases abstractas para declarar tipos de variables, tipos de parámetros, tipos de devolución de métodos y tipos de datos. Conversión, etc.
Intente usar la capa abstracta para programar en el programa y escriba la clase específica en el archivo de configuración.
Para la programación de capa abstracta, inyecte el objeto de la clase específica en otros objetos a través de Inyección de dependencia (Inyección de dependencia, DI )
Construya el
ajuste de inyección Inyección (Inyección Setter)
Interfaz Inyección
Principio de aislamiento de interfaz:
Un cliente no debe depender de interfaces que no necesita.
Principio de segregación de interfaces (ISP): los clientes no deben verse obligados a depender de interfaces que no utilizan.
Análisis del principio de segregación de la interfaz
Cuando una interfaz es demasiado grande, debe dividirse en interfaces más pequeñas.
Los clientes que usan esta interfaz solo necesitan conocer los métodos relacionados
. Haga lo que no debe hacer y haga lo que debe hacer.
Definición de "interfaz" (1): una colección de todas las características del método proporcionadas por un tipo. Una interfaz representa un rol, y cada rol tiene su propia interfaz específica "Principio de segregación de roles"
Definición de "interfaz" (2): interfaz específica del idioma definida de manera estrecha. La interfaz solo proporciona el comportamiento que el cliente necesita, y el comportamiento que el cliente no necesita está oculto. Se debe proporcionar al cliente una interfaz única lo más pequeña posible, en lugar de proporcionar una interfaz total grande. Cada interfaz contiene solo una cliente.método requerido, "servicio personalizado"
Principios de multiplexación sintética:
Priorice el uso de la composición de objetos en lugar de la herencia para lograr el propósito de reutilización.
Principio de reutilización compuesta (CRP): favorece la composición de objetos sobre la herencia como mecanismo de reutilización.
Análisis del principio de reutilización sintética El
principio de reutilización sintética consiste en utilizar algunos objetos existentes en un nuevo objeto a través de una relación de asociación (incluidas la relación de combinación y la relación de agregación), convirtiéndolo en parte del nuevo objeto. El nuevo objeto llama al objeto existente a través de la delegación. El
método para lograr el propósito de la función de reutilización
Cuando reutilice, trate de usar una relación de combinación/agregación (relación de asociación), y use menos herencia Reutilización de herencia
: simple de implementar y fácil de expandir. Destruye el encapsulamiento del sistema; la implementación heredada de la clase base es estática, es imposible cambiar en tiempo de ejecución y no hay suficiente flexibilidad; solo se puede usar en un entorno limitado. (reutilización de "caja blanca")
reutilización compositiva/agregada: acoplamiento relativamente bajo, las operaciones en los objetos miembros se invocan selectivamente; se pueden realizar dinámicamente en tiempo de ejecución, los objetos nuevos pueden hacer referencia dinámicamente a otros objetos del mismo tipo que los objetos miembros. (multiplexación de "caja negra")
Ley de Dimit:
Cada unidad de software tiene solo un conocimiento mínimo de otras unidades y está limitada a aquellas unidades de software estrechamente relacionadas con la unidad.
Ley de Deméter (LoD): cada unidad debe tener solo un conocimiento limitado sobre otras unidades: solo unidades "estrechamente" relacionadas con la unidad actual.
Análisis de la Ley de Dimiter La
Ley de Dimiter requiere que una entidad de software interactúe con otras entidades lo menos posible. La
aplicación de la Ley de Dimiter puede reducir el grado de acoplamiento del sistema y mantener la relación débilmente acoplada entre clases
. extraños).
Solo comuníquese con sus amigos directos (Hable solo con sus amigos inmediatos).
(1) El objeto actual en sí mismo (esto)
(2) Se pasa como un parámetro al método del objeto actual Objetos en
(3) Objetos miembros del objeto actual
(4) Si los objetos miembros del objeto actual son una colección, entonces los elementos de la colección también son amigos (5) Cualquier objeto
creado por el objeto actual El grado de acoplamiento del sistema, el cambio de un objeto no afectará a muchos otros objetos La ley de Dimiter requiere que al diseñar el sistema, la interacción entre los objetos debe ser minimizado. Si dos objetos no tienen que comunicarse directamente entre sí, entonces esto No debería haber ninguna interacción directa entre dos objetos. Si uno de los objetos necesita llamar al método de otro objeto, la llamada se puede reenviar a través de un "tercero" para reducir la distancia entre los objetos existentes mediante la introducción de un "tercero" razonable.
Puntos a tener en cuenta al aplicar la ley de Dimit:
En términos de división de clases, se deben crear clases débilmente acopladas tanto como sea posible. Cuanto menor sea el grado de acoplamiento entre clases, más propicio para la reutilización. Una vez que se modifica una clase en acoplamiento flexible, no tendrá demasiado impacto en la clase asociada
En el diseño estructural de la clase, cada clase debe minimizar los derechos de acceso de sus variables miembro y funciones miembro
En el diseño de la clase, siempre que sea posible, un tipo debe diseñarse como una clase invariable
Un objeto debe minimizar sus referencias a otros objetos en términos de referencias a otras clases