principios de diseño
TRANSCRIPT
![Page 2: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/2.jpg)
● Introducción● DRY + SOLID + IoC + COC● GRASP● Inmutabilidad y Funciones● Closure
Agenda
![Page 3: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/3.jpg)
Introducción
![Page 4: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/4.jpg)
● 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
![Page 5: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/5.jpg)
● 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
![Page 6: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/6.jpg)
![Page 7: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/7.jpg)
y Principios Relacionados
SOLID
![Page 8: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/8.jpg)
![Page 9: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/9.jpg)
● 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)
![Page 10: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/10.jpg)
![Page 11: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/11.jpg)
● 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)
![Page 12: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/12.jpg)
![Page 13: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/13.jpg)
● 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)
![Page 14: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/14.jpg)
![Page 15: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/15.jpg)
● 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)
![Page 16: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/16.jpg)
![Page 17: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/17.jpg)
● 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)
![Page 18: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/18.jpg)
● 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)
![Page 19: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/19.jpg)
![Page 20: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/20.jpg)
● 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)
![Page 21: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/21.jpg)
● 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
![Page 22: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/22.jpg)
● 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)
![Page 23: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/23.jpg)
● SRP: Single Responsibility Principle● OCP: Open-Closed Principle● LSP: Liskov Substitution Principle● ISP: Interface Segregation Principle● DIP: Dependency Inversion Principle
SOLID
![Page 24: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/24.jpg)
General Responsibility AssignmentSoftware Principle
GRASP
![Page 25: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/25.jpg)
● Information Expert● Creator● Indirection● Low Coupling● High Cohesion● Controller● Polymorphism● Protected Variations● Pure Fabrication
GRASP
![Page 26: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/26.jpg)
● Asignar la responsabilidad a la clase que conoce toda la información necesaria
● Dada una responsabilidad, ¿qué clase debería cumplirla?
● Favorece el Encapsulamiento, ya que los objetos utilizan su propia información para llevar a cabo sus tareas
● Recordar SRP
Experto en Información
![Page 27: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/27.jpg)
● ¿Quién debe crear el objeto X?○ Quien tenga la información necesaria para
realizar la creación del objeto○ Quien usa directamente las instancias
creadas del objeto○ Quien almacena o maneja varias instancias
de la clase○ Quien contiene o agrega la clase
● Patrón Factory, DIP, IOC
Creador
![Page 28: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/28.jpg)
● ¿Cómo minimizar las dependencias entre módulos?
● Cuando una clase, paquete o módulo depende de otro, se dice que ambos están acoplados
● Tener los módulos lo menos ligados entre sí que se pueda
Bajo Acoplamiento
![Page 29: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/29.jpg)
● La información que almacena una clase debe de ser coherente y debe estar relacionada con la clase
● ¿Qué tan fuertemente relacionadas y enfocadas son las responsabilidades de una clase?
● Recordar SRP y Information Expert
Alta Cohesión
![Page 30: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/30.jpg)
● Dada una UI y una capa de negocio, ¿quién tiene la responsabilidad de recibir los pedidos de la UI y comunicarse con el negocio?
● Sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, separando la lógica de presentación de la lógica de negocio
● Relacionado con MVC
Controller
![Page 31: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/31.jpg)
● Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo
● Cuando el comportamiento varían según el tipo
● Para crear componentes conectables● Recordar OCP y LSP● Anti-principio:
○ instanceof
Polimorfismo
![Page 32: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/32.jpg)
● Se da en las clases que no representan un ente u objeto real del problema
● Es una clase "inventada" que mejora estructuralmente el sistema
● Ejemplos:○ DDD: clases Service○ JPA: EntityManager
● Anti-principio:○ Clases Función o Algoritmo, con un solo
método
Fabricación Pura
![Page 33: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/33.jpg)
● ¿Cómo desacoplo dos clases? ¡Pues agregando una clase intermedia!
● Objeto Mediador● Patrón Delegation● Puede ser útil por ejemplo para
encapsular una API externa y proteger a nuestra aplicación de futuros cambios de esa API
Indirección
![Page 34: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/34.jpg)
● Para protegernos del cambio, nada mejor que trabajar con interfaces
● Diseño por Contrato● Usando el Polimorfismo, podemos
extender el sistema simplemente creando otra implementación
● Recordar OCP y LSP● También podemos protegernos con la
Indirección y el patrón Delegation
Variaciones Protegidas
![Page 35: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/35.jpg)
y Side-Effect Free Functions
Inmutabilidad
![Page 36: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/36.jpg)
Objetos Indep. del Contexto● Objetos Inmutables
○ Todos sus atributos son Read-Only● Objetos Stateless
○ No tiene atributos● Objetos con Estado Independiente del
Contexto○ El estado es compartido por todos○ Ningún contexto puede modificar su estado○ Ejemplo: Una clase de Configuración
![Page 37: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/37.jpg)
● Read-only● No se les puede cambiar el estado● No pueden ser corrompidos● Thread-Safe por naturaleza● En DDD es ideal que los ValueObject sean
implementados como Objetos Inmutables● Overhead por cantidad de objetos:
¡Despreciable! (sino Flyweight Pattern)
Objetos Inmutables
![Page 38: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/38.jpg)
● No proveerás setters● Todos los atributos serán privados y final● No permitirás a subclases sobreescribir
métodos (la clase será final o el constructor privado y métodos factory)
● Si el objeto inmutable debe contener la referencia a un objeto mutable, entonces...
Reglas de Inmutabilidad para Java
![Page 39: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/39.jpg)
● No escribirás métodos que modifiquen el objeto mutable
● No compartirás referencias del objeto mutable
● Crearás copias y guardarás referencias a esas copias
● Crearás copias de tu objeto mutable interno cuando tengas que devolverlo en algún getter
Para Referencias a Obj Mutables
![Page 40: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/40.jpg)
● Se dice que una función o expresión está libre de efectos colaterales o secundarios si ésta no modifica el estado de su entorno, independientemente del valor que devuelva
Side-Effect Free Functions (1)
![Page 41: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/41.jpg)
● Operaciones○ Comandos: introducen un cambio en el
sistema (Ej: los setters)○ Consultas: obtienen info del sistema sin
modificarlo (Ej: los getters)● Las funciones devuelven un resultado sin
producir un efecto secundario● Las funciones idempotentes están libres
de efectos secundarios por definición
Side-Effect Free Functions (2)
![Page 42: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/42.jpg)
● Las funciones son más fáciles de probar que los comandos
● Las funciones implican menor riesgo● Best Practice: Mantener separados los
comandos de las consultas● Best Practice: Siempre que se pueda,
devolver un objeto inmutable como resultado de un cálculo
Side-Effect Free Functions (3)
![Page 43: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/43.jpg)
● Todas las operaciones de un objeto inmutable deberían ser funciones
Side-Effect Free Functions (4)
![Page 44: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/44.jpg)
... inventáramos un lenguaje donde sólo se pudieran crear funciones y no existieran los estados?
¿Qué tal si...
![Page 45: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/45.jpg)
Más allá de la ProgramaciónOrientada a Objetos
Otros Mundos
![Page 46: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/46.jpg)
Paradigmas de Programación● Imperativo (Ej: Pascal, C, Basic)● Orientado a Objetos (Ej: Smalltalk, Ruby,
Java, C++)● Funcional (Ej: Haskell, Scheme, Lisp)● Lógico (Ej: Prolog)● Declarativo (Ej: DSL: HTML, Logo,
Matlab, SQL)
![Page 47: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/47.jpg)
● Entorno privado de variables cuya existencia se propaga a lo largo de todas las ejecuciones de un bloque de código
● Puede ser usada para asociar una función con un conjunto de variables privadas que persisten en las invocaciones de la función
Closure (1)
![Page 48: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/48.jpg)
● Entorno cerrado de variables● Java brinda Closures a través de:
○ Clases Anónimas Internas○ La API de Reflection
● JavaScript y otros Lenguajes proveen Closures con una sintaxis más natural (más nativa)
● En JavaScript, si se declara una función dentro de otra => Closure
Closure (2)
![Page 49: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/49.jpg)
Más allá de los Principios de Diseño
Conclusión
![Page 50: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/50.jpg)
![Page 51: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/51.jpg)
KISS (Keep It Simple, Stupid)
![Page 52: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/52.jpg)
● Patrones de Diseño● Patrones de Arquitectura● Patrones de Aplicaciones Enterprise● Domain-Driven Design● Atributos de Calidad● Domain Specific Languages● ¡Ponete un ArgenChino y Dejá de Robar!
Ideas para Próximas Charlas
![Page 53: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/53.jpg)
● Robert C. Martin (Uncle Bob) - SOLID● http://lostechies.
com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
● Craig Larman - GRASP● http://www.arquitecturajava.com/● http://www.slideshare.net/snmgian/grasp-
principles● Wikipedia● JavaScript Closures for Dummies (post)
Bibliografía
![Page 54: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/54.jpg)
https://github.com/elfrasco/design-principles
Código Fuente
![Page 55: Principios de diseño](https://reader033.vdocumento.com/reader033/viewer/2022052213/55be051abb61eba0108b4645/html5/thumbnails/55.jpg)