¿Cuántos principios tiene el diseño de patrones?
Categories:
Los principios de diseño de patrones originalmente se resumieron en solo 5, conocidos como SOLID:
Principio de Responsabilidad Única (Single Responsibility Principle, SRP): Una clase debe tener una única razón para cambiar, es decir, una clase debe tener una única responsabilidad.Principio de Abierto/Cerrado (Open/Closed Principle, OCP): Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para la extensión, pero cerradas para la modificación. Es decir, los cambios deben implementarse mediante extensión en lugar de modificar el código existente.Principio de Sustitución de Liskov (Liskov Substitution Principle, LSP): Los tipos derivados deben poder reemplazar a sus tipos base. Es decir, una subclase debe poder reemplazar a su superclase sin afectar la corrección del programa.Principio de Segregación de Interfaces (Interface Segregation Principle, ISP): No se debe obligar a los clientes a depender de interfaces que no utilizan. Se deben dividir las interfaces grandes en interfaces más pequeñas y específicas, de modo que los clientes solo conozcan los métodos que necesitan usar.Principio de Inversión de Dependencias (Dependency Inversion Principle, 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 detalles de implementación, sino que los detalles de implementación deben depender de abstracciones.
Posteriormente se añadieron dos reglas más. Estas reglas añadidas posteriormente son más específicas y más orientadoras que las anteriores. Podemos observar en las explicaciones de los principios que SOLID describe qué hacer, mientras que las reglas añadidas describen qué hacer preferentemente o lo mejor posible.
Principio de Reutilización por Composición/Agregación (Composition/Aggregation Reuse Principle, CARP): Se debe priorizar el uso de la composición (síntesis) y la agregación de objetos en lugar de la herencia para lograr la reutilización del código.Ley de Deméter (Law of Demeter, LoD): Un objeto debe conocer lo menos posible a otros objetos, es decir, un objeto debe saber lo menos posible sobre la estructura interna y los detalles de implementación de otros objetos.
Además de los principios de diseño mencionados anteriormente, existen otros principios de diseño que, aunque no son tan conocidos, también tienen una importante función de orientación en el diseño y la arquitectura del software. Estas reglas propuestas posteriormente resultan un poco redundantes, al menos considero que no son contraintuitivas y no requieren una profunda reflexión.
Principio del Conocimiento Mínimo (Principle of Least Knowledge, PoLK): También conocido como una extensión de la Ley de Deméter, sostiene que un objeto debe conocer la menor información posible sobre otros objetos. Este principio se remonta a 1987, cuando Patricia Lago y Koos Visser propusieron la “Ley de Comunicación Mínima”.Principio de Dependencias Estables (Stable Dependencies Principle, SDP): Este principio sostiene que el diseño de software debe asegurar que los componentes estables no dependan de componentes inestables, es decir, los componentes más estables deben depender menos de los componentes menos estables. Este principio proviene del estudio profundo de las relaciones entre componentes en sistemas de software.Principio de Abstracción Estable (Stable Abstraction Principle, SAP): En consonancia con el principio de dependencias estables, este principio guía la coincidencia de la abstracción con la estabilidad, es decir, los componentes estables deben ser abstractos, mientras que los componentes inestables deben ser concretos. Este principio ayuda a asegurar la estabilidad y flexibilidad del sistema de software.