solid
TRANSCRIPT
Introducción
● Rigidez○ Dificultad para implementar cambios
● Fragilidad○ Tendencia a romperse con cada cambio
● Inmovilidad○ Inhabilidad de reutilizar el código
● Viscosidad○ Del Diseño: los hacks son muy sencillos○ Del Ambiente: lento e ineficiente
Síntomas de un Diseño Podrido
● Cambios en los Requerimientos○ Inicialmente no contemplados
● Administración de Dependencias○ Es la arquitectura de dependencias la que
se va degradando
Causas que Aceleran la Entropía
y Principios Relacionados
SOLID
● Cualquier funcionalidad existente en un programa debe existir de forma única
● Anti-principios:○ WET: Write Everything Twice○ WETTT: Write Everything Ten Throusand
Times○ Copy & Paste
DRY (Don't Repeat Yourself)
● Todo componente debe tener una única responsabilidad
● Una clase, al tener una única responsabilidad, sólo debe ser alterada a través de un cambio en dicha responsabilidad
● No debe existir más de una razón para cambiar una clase
SRP (Single Responsibility)
● Abierto a la Extensibilidad● Cerrado a las Modificaciones● Debemos poder añadir nueva
funcionalidad a la aplicación sin tener que alterar el código ya construido
OCP (Open-Closed Principle)
● Las clases hijas deben poder ser tratadas como las clases padre
● Diseño por Contrato (interfaces)● Un usuario de una clase base debe
continuar funcionando apropiadamente en el sistema independientemente de qué clase derivada se utilice
● Podremos cambiar comportamiento creando una nueva clase hija y sobreescribiendo comportamiento
LSP (Liskov Substitution)
● Una clase cliente A que tiene una dependencia con la clase B no debe verse forzada a depender de métodos de la clase B que no vaya a usar jamás
● Es preferible muchas interfaces con pocos métodos a pocas interfaces con muchos métodos
● Las interfaces son el contrato del comportamiento (son declarativas)
ISP (Interface Segregation)
● El control de la construcción de los objetos no recae en el desarrollador, sino que es otra clase o conjunto de clases las que se encargan de construir los objetos que necesitamos
● Al trabajar con interfaces y no crear las implementaciones, invertimos el control de ejecución del código
● En camino a un Diseño Declarativo
IOC (Inversion of Control)
● Los componentes deben depender de abstracciones, no de implementaciones concretas
● Las dependencias que una clase tiene no deben ser asignadas por ella misma sino por un agente externo (Contenedor)
● Inyección de Dependencia● Reflection, Spring, EJB, CDI
DIP (Dependency Inversion)
● Don't call us, we'll call you● Relacionado con IoC y DIP● Favorece el Bajo Acoplamiento● Favorece la Alta Cohesión
Principio de Hollywood
● Antes de abordar el desarrollo, un programador puede declarar una serie de convenciones que le permiten asumir una configuración por defecto del sistema
● Configuración por default● Rapid Development● Ruby on Rails, Seam, Spring Roo
COC (Convention Over Config)
● SRP: Single Responsibility Principle● OCP: Open-Closed Principle● LSP: Liskov Substitution Principle● ISP: Interface Segregation Principle● DIP: Dependency Inversion Principle
SOLID
Más allá de los Principios de Diseño
Conclusión
KISS (Keep It Simple, Stupid)
● Robert C. Martin (Uncle Bob)● http://lostechies.
com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
● Wikipedia
Bibliografía
Código Fuentehttps://github.com/
elfrasco/design-principles
