1. Principios de Diseño
adrianparedes82@gmail.com
@aparedes82
http://elblogdelfrasco.blogspot.com

2. Introducción

3. ● 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

4. ● 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

6. y Principios Relacionados
SOLID

8. ● 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)

10. ● 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)

12. ● 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)

14. ● 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)

16. ● 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)

17. ● 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)

19. ● 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)

20. ● 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

21. ● 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)

22. ● SRP: Single Responsibility Principle
● OCP: Open-Closed Principle
● LSP: Liskov Substitution Principle
● ISP: Interface Segregation Principle
● DIP: Dependency Inversion Principle
SOLID

23. Más allá de los Principios de Diseño
Conclusión

25. KISS (Keep It Simple, Stupid)

26. ● Robert C. Martin (Uncle Bob)
● http://lostechies.
com/derickbailey/2009/02/11/solid-
development-principles-in-motivational-
pictures/
● Wikipedia
Bibliografía

27. Código Fuente
https://github.com/
elfrasco/design-principles