VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Practicando con
Patrones de diseño
9 patrones indispensables y populares
Con laboratorios ¡Aplica ya!, paso a paso.
Código
ódigo descargable
descargable.
Plus: aplicando los principios SOLID.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
CONTENIDO
CONTENIDO _________________________________________________________________ 2
INTRODUCCIÓN A LOS PATRONES DE DISEÑO ______________________________________ 4
Lección: El concepto patrones en la ingeniería de software ________________________________ 4
¿Qué es un patrón de diseño? ________________________________________________________________ 4
Clasificación de los patrones de diseño _________________________________________________________ 5
Patrones más populares ________________________________________________________________ 6
LOS PATRONES MÁS POPULARES Y CASOS DE ESTUDIO ______________________________ 7
UNO: Patrón Abstract Factory ________________________________________________________ 7
Diagrama genérico _________________________________________________________________________ 8
Secuencia de Clases y objetos participantes ____________________________________________________ 9
Caso de estudio: Patrón Abstract Factory ______________________________________________________ 10
Diagrama de clases final del caso de estudio ___________________________________________________ 11
DOS: Patrón Factory Method ________________________________________________________ 12
Diagrama genérico ________________________________________________________________________ 13
Secuencia de Clases y objetos participantes ___________________________________________________ 14
Caso de estudio: Patrón Factory Method ______________________________________________________ 15
Diagrama de clases final del caso de estudio ___________________________________________________ 16
TRES : Patrón Adapter _____________________________________________________________ 18
Diagrama genérico ________________________________________________________________________ 19
Secuencia de Clases y objetos participantes ___________________________________________________ 19
Caso de estudio: Patrón Adapter _____________________________________________________________ 20
Diagrama de clases final del caso de estudio ___________________________________________________ 21
CUATRO: Patrón Decorator _________________________________________________________ 22
Diagrama genérico ________________________________________________________________________ 23
Secuencia de Clases y objetos participantes ___________________________________________________ 24
Caso de estudio: Patrón Decorator ___________________________________________________________ 25
Diagrama de clases final del caso de estudio ___________________________________________________ 25
CINCO: Patrón Composite __________________________________________________________ 27
Diagrama genérico ________________________________________________________________________ 28
Secuencia de Clases y objetos participantes ___________________________________________________ 28
Caso de estudio: Patrón Composite __________________________________________________________ 29
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama de clases final del caso de estudio ___________________________________________________ 29
SEIS : Patrón Observer _____________________________________________________________ 31
Diagrama genérico ________________________________________________________________________ 32
Secuencia de Clases y objetos participantes ___________________________________________________ 32
Caso de estudio: Patrón Observer ____________________________________________________________ 33
Diagrama de clases final del caso de estudio ___________________________________________________ 34
SIETE : Patrón Strategy _____________________________________________________________ 35
Diagrama genérico ________________________________________________________________________ 36
Secuencia de Clases y objetos participantes ___________________________________________________ 36
Caso de estudio: Patrón Strategy ____________________________________________________________ 37
Diagrama de clases final del caso de estudio ___________________________________________________ 37
OCHO : Patrón State _______________________________________________________________ 39
Diagrama genérico ________________________________________________________________________ 39
Secuencia de Clases y objetos participantes ___________________________________________________ 40
Caso de estudio: Patrón State _______________________________________________________________ 41
Diagrama de clases final del caso de estudio ___________________________________________________ 41
NUEVE : Patrón Facade ____________________________________________________________ 43
Diagrama genérico ________________________________________________________________________ 43
Secuencia de Clases y objetos participantes ___________________________________________________ 44
Caso de estudio: Patrón Facade______________________________________________________________ 44
Reafirme sus conocimientos ________________________________________________________________ 46
Siguiente paso nivel avanzado II ________________________________________________ 48
SINGLE PAGES APPLICATION: ¡Diseño de una tienda con Blazor! ___________________________ 48
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
PARTE
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
1
INTRODUCCIÓN
DUCCIÓN A LOS
PATRONES DE DISEÑO
Después de esta lección aprenderá:
1. El origen y clasificación
ón de los patrones de diseño de software
2. Entender el concepto Abstract Factory pattern
pattern,, su diagrama genérico, ventajas y desventajas
3. Practicar con un caso de estudio aplicando el patrón en el vídeo laboratorio ¡Aplica ya!
El Aprendizaje Hecho Fácil!
¿Qué es un patrón de diseño?
El concepto universal de diseño recurrente de software
Para el año 1994, el grupo de ingenieros conocidos como Gang of Four (GoF),, crearon una
publicación producto de su experiencia e investigaci
investigación, conocida como Design Patterns,
Patterns que
contiene un total de 23 patrones para el diseño de software.
La Teoría General de Sistemas, vista en primeros semestres de ingeni
ingeniería,
ería, indica que un sistema
abierto posee una fuerte carga de entropía. No es difícil comprender que la ingeniería de
software haya lidiado por décadas, con el desarrollo de los algoritmos,, la lógica de negocio, y en
general, los retos que presentann innumerables necesidades de software en el mundo. Sin contar
con la imaginación, hábitos de programación y proliferación de aplicaciones Web. Dicho esto,
los patrones de diseño de software, son equivalentes a las hormas o plantillas, que sirven de
herramientas para
ara brindar soluciones estandarizadas a patrones de programación reiterativos, y
algoritmia común o persistente
persistente. Equivalen a los planos estructurales básicos que facilitan la
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
resolución de retos relacionados con el diseño de planos prefabricados que pueden
personalizarse para resolver un problema de diseño de código, algoritmia y software.
No se debe confundir la algoritmia con un patrón. Estos últimos brinda el enfoque, la técnica
para hacer de la algoritmia un proceso orientado a la buena calidad de software, resolviendo a
nivel abstracto y genérico, los retos de diseño de software.
Clasificación de los patrones de diseño
Todo se puede categorizar
La arquitectura e ingeniería de software, puede ser transversal y universal para enfrentar los
retos el diseño de software, encontrando similitudes, necesidades y comportamientos comunes
para una gran diversidad de soluciones, independientemente del lenguaje de programación y
los frameworks. Los patrones se categorizaron y clasificaron así:
1. Creacionales
2. Estructurales
3. Comportamentales
Observe en la imagen la clasificación:
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Patrones más populares
Aunque todos los patrones se crearon con propósitos específicos para atender requerimientos
con diseños puntuales, en general la clasificación por mayor uso (1- 5) sería la siguiente:
Categoría Patrón Nivel de uso
Abstract Factory 5
Creacionales Factory Method 5
Singleton 4
Facade 5
Adapter 4
Estructurales
Composite 4
Proxy 4
Observer 5
Strategy 5
Comportamiento
Iterator 5x
Command 4, x
El patrón Singleton es ampliamente utilizado en el curso completo “API con Clean architecture”
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
PARTE
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
2
LOS PATRONES MÁS
POPULARES Y CASOS DE
ESTUDIO
Este patrón se caracteriza por generar objetos de categorías similares ssin
in especificación de sus
clases abstractas.
Ventajas:
1. Compatibilidad de objetos.
2. Disminución de acoplamiento de código y dependencias.
3. El principio de responsabilidad única facilita su mantenimiento.
4. Facilidad de insertar nuevas variantes.
Desventajas:
El código puede ser más complejo por la gran variedad de interfaces.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Fuente: Diseño VladoDotNet
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Secuencia de Clases y objetos participantes
Para este patrón se incluye una columna adicional (Clase), detallando parte del código
desarrollado en el laboratorio (para descargas ir al link a pie de página) 1
Participante Clase Descripción
public abstract class AProyectoFactory
Especializaríamos una fábrica abstracta,
public abstract IPrySeminarios que se encargaría de facilitar la
CrearProyectoSeminarios(string ‘producción’ de los diferentes
FÁBRICA ABSTRACTA ( I )
modalidad); productos/servicios para distintas fábricas
public abstract IPryInvestigacion o sedes (concretas), a través de sus
CrearProyectosInvestigacion(string métodos abstractos.
modalidad);
public class SedeSur:AProyectoFactory
Cada fábrica podrá generar productos o
public override IPrySeminarios proyectos. Implementan la Abstract
CrearProyectoSeminarios(string modalidad) Factory, AProyectoFactory.
return new Los productos concretos se logran gracias
a la implementación de los miembros o
ProyectosSeminarios(modalidad);
FÁBRICAS CONCRETAS ( II ) métodos abstractos (override) de la
public override IPryInvestigacion factoría abstracta.
CrearProyectosInvestigacion(string
modalidad) Observe que la fábrica hace uso de esta
fábrica CONCRETA:
public class SedeNorte:AProyectoFactory ProyectosSeminarios
… métodos override similares
public class ProyectosInvestigacion : Observe que ambas firmas representan la
IPryInvestigacion implementación de las interfaces
respectivas:
public class ProyectosSeminarios :
PRODUCTOS CONCRETOS IPrySeminarios interface IPryInvestigacion,
( III ) interface IPrySeminarios
CrearProyectoSeminarios(string modalidad)
Y se especializan en crear (concreto)
public string CrearProyecto(string productos/proyectos con sus respectivos
modalidad) métodos (en este caso coinciden en el
nombre)
public class Cliente Tenemos una clase Cliente que se
especializa en interactuar con la factoría o
CLIENTE ( IV ) //constructor
Abstract Factory para solicitar el proceso
El cliente generalmente se public Cliente(AProyectoFactory factory,
string modalidad) de creación de proyectos (producto).
compone con la lógica de
negocio. public async Task<string>
CrearProyectosSeminarios(string Hace uso del método
modalidad) CrearProyectosSeminarios( )
1
https://vladodotnet.wordpress.com/
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Caso de estudio: Patrón Abstract Factory
Ahora apliquemos el siguiente caso de estudio con el Patrón Abstract Factory:
Caso de estudio : Produ
Producción de proyectos
Requerimiento:
Las directivas de la Escuela Norte han establecido producir una serie de productos académicos que deberán crear
todas las sedes (fábricas) así:
La creación de proyectos institucionales en la categorías:
o Seminarios,
o Investigación,
o Y social.
Cada uno de ellos se ofrecerá en las modalidades:
o Presencial y
o Remoto.
Los productos deben ser creado por todas las sedes de la escuela (norte y sur).
El Aprendizaje Hecho Fácil!
El anterior requerimiento amerita aplicar el patrón Abstract Factory,, ideal para sistemas de
producción de objetos o servicios del mismo género y presentados en distintas variantes
jerárgicas. Identifique los actores antes para el caso de estudio, en el cuadro anterior
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Así que para cada variante o modalidad de proyecto, crearemos una fábrica especializada
independiente que implementa la fábrica principal,, base o interface o abstracta para atender
el requerimiento anterior.
Diagrama de clases final del caso de estudio
DI Fábricas concretas
Productos concretos
Código: Caso Abstract
tract Factory
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Patrón de diseño creado que proporciona una interfaz para crear objetos en una superclase,
pero permite que las subclases alteren el tipo de objetos que se crearán, es decir, facilita que
las subclases decidan de qué clase crear instancias.
Agregar una nueva clase al programa no es tan simple si el resto del código ya está acoplado a
las clases existentes. Con este patrón siempre que todas las clases de producto implementen
una interfaz común, puede pasar sus objetos al código de cliente sin interrumpirlo.
Así, el código basado en este patrón ofrece gran flexibilidad para crear objetos. La clase
abstract proporciona un objeto predeterminado, pero las subclases podrán generar una
instancia de una versión extendida del objeto.
Ventajas
1. Evitas el acoplamiento estrecho entre el creador y los productos concretos.
2. Principio de responsabilidad única. Puede mover el código de creación del producto a un
solo lugar del programa, lo que facilita el soporte del código.
3. Principio abierto/cerrado. Puede introducir nuevos tipos de productos en el programa sin
romper el código de cliente existente.
Desventajas
1. El código puede volverse más complicado ya que necesita introducir muchas subclases
nuevas para implementar el patrón. El mejor de los casos es cuando se introduce el patrón
en una jerarquía existente de clases de creador.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Secuencia de Clases y objetos participantes
Participante Clase Descripción
IPRODUCTO ( I ) Define los detalles de la producción,
Revista semestral de public Interface IRevistasAcedemica como el nombre y tipo de publicación
investigación académica (objeto).
Clase abstracta que determina el tipo de
CREATOR BASE ( II ) public abstract class producción.
Publicaciones académicas. FactoryMethodBase
El método retornará el tipo de producto
Una publicación puede ser un protected abstract IRevistasAcedemica según la interfaz declarada, para este
libro, revista, blog online, etc. CrearPublicacion(); caso, productos o publicaciones de tipo
Revistas académicas. (punto anterior)
Estas clases corresponden a las subclases
que equivalen a los servicios o
implementación de las interfaces.
Estas deciden/seleccionan que clases
instanciar.
public class RevistasIoTFactory : En este caso, se decide instanciar
FactoryMethodBase
La línea de InvestigaciónIoT
protected override IRevistasAcedemica
CREATOR CONCRETO ( IV ) CrearPublicacion()
Tipos de publicaciones: Las fábricas contendrán el método
Revistas, Libros, Informes, public override IRevistasAcedemicas sobrescrito para la producción de
artículos de investigación. CrearPublicacion() publicaciones. El Creator Concret
{ sobrescribe el método de la fábrica
IRevistasAcedemicas oProducto =
abstracta Creator,
new InvestigacionIoT();
return oProducto; CrarPublicacion( )
} retornando la instancia de un producto
concreto (línea), InvestigacionIoT( ).
El porducto en este ejemplo corresponde
a la línea, del punto (III), que ha sido
seleccionado.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Caso de estudio: Patrón Factory Method
Caso de estudio : Producción de publicaciones académicas
Requerimiento
Las directivas de la Escuela Norte han ingresado en el mundo de la editorial de publicaciones académicas.
Se producirán publicaciones académicas para cubrir inicialmente distintas necesidades de la escuela
de ingeniería de sistemas.
La decanatura
tura y el departamento de investigación crearán una revista semestral con temáticas
asociadas a las líneas de investigación de:
o Ingeniería de software,
o IoT,
o Lenguajes de programación.
Finalmente, deberá generarse
generarse:
o un informe consolidado del total de revistas
vistas producidas por cada línea de investigación.
o Un artículo de investigación
investigación, con el resumen del contenido.
El Aprendizaje Hecho Fácil!
El requerimiento podríamos atenderlo haciendo uso del patrón Factory Method.. Observe que se
generan objetos derivados
rivados de la clase abstracta similares: Una publicación puede ser tanto una
revista como un artículo con el resumen del contenido
contenido. Tenemos entonces un resumen de los
participantes en este patrón así:
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
El Cliente
Para este patrón el participante Cliente
Cliente, será el Main o la UI, que al ser un proyecto de tipo
Console, corresponde a la clase Program o Main,, con dos partes del código a destacar:
La instanciación, para la creación de un objeto de tipo IRevistasAcedemicas. El constructor
inicializa el servicio o implementación de la interfaz anterior, y que corresponde a una de las
fábricas,s, inicialmente, revistas dedicadas a la investigación de IoT, RevistasIoTFactory():
// FABRICA DE REVISTAS PARA IoT
IRevistasAcedemicas oRevista = new RevistasIoTFactory().CrearPublicacion();
La anterior línea cumple el objetivo del patrón Factory Method,, debido a que crea y retorna una
instancia del producto, y deja o permite que las subclases, por ejemplo —RevistasIoTFactory() —,
decidan cuál clase instanciar, en este ccaso, el producido de revistas IoT.
La segunda línea a destacar es la solicitud del cliente para la producción de revistas de
investigación de IoT, y el retorno del nombre y tipo de producción realizada por la respectiva
fábrica concreta:
oRevista.GetNombreRevista() y oRevista
oRevista.TipoPublicacion()
Ahora observe
bserve a continuación el diagrama de clases final del diseño, aplicando este patrón.
Diagrama de clases final del caso de estudio
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Código: Caso Factory Method
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Este patrón de diseño convierte la interface de una clase en otra interface que los clientes
requieren, facilitando que las clases trabajen de manera colaborativa. Equivale a una clase
intermedia. Esto permite ir más allá de aplicaciones con interfaces incompatibles con nuevos
servicios o adiciones. Así, los oobjetos tipo Adapter podrán convierte la interfaz de un objeto
para que otro objeto pueda entenderlo.
El adaptador podrá convertir datos en varios formatos, y adicionalmente ayudar a colaborar a
objetos con diferentes interfaces, gracia a su diseño para pasar la solicitud del objeto
incompatible en el formato solicitado. Esto se similar a los adaptadores que se utilizan para
aparatos electrónicos y poder funcionar con otros estándares o diseños internacionales.
Ventajas
1. Principio abierto/cerrado. Puede introducir nuevos tipos de adaptadores en el programa
sin romper el código de cliente existente, siempre que funcionen con los adaptadores a
través de la interfaz del cliente.
2. Principio de responsabilidad única. Puede separar la interfaz o el código de conversión de
datos de la lógica empresarial principal del programa.
Desventajas
1. La complejidad del código porque se requiere agregar un conjunto de nuevas interfaces
y clases.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Secuencia de Clases y objetos participantes
Participante Descripción
ITARGET BASE ( I ) La interfaz de cliente describe un protocolo que otras clases deben seguir para poder
colaborar con el código de cliente.
Implementa la interfaz ITargetBase inicialmente para los objetos adaptados que ya forman
ADAPTADOS ( II )
parte del sistema. (Profesor del planta)
ADAPTEE- SERVICIO ( III ) El Servicio es una clase útil.
Adaptee (a adaptar) El cliente no puede usar esta clase directamente porque tiene una interfaz incompatible.
Request de servicios incompatibles (Nuevo servicio para profesores virtuales, a adaptar)
El adaptador del servicio incomplatible.
Implementa la clase base, ITargetBase.
ADAPTER ( IV )
Debe tener un constructor que crea una instancia de un tipo de requerimiento diferente;
Soluciona la incompatibilidad.
instancia de Adaptee.
El cliente es una clase que contiene la lógica de negocios existente del programa.
CLIENTE UI ( V ) Interactúa con el adaptador a través de la interfaz del cliente. Gracias a esto, puede
introducir nuevos tipos de adaptadores en el programa sin romper el código de cliente.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Caso de estudio: Patrón Adapter
Tenemos entonces un resumen de los participantes en este patrón así:
Caso de estudio : Adapter
Requerimiento
La escuela actualmente
almente ofrece servicios web a profesores de planta la gestión de cursos, salones, agenda de
horarios y atención a los estudiantes.
El próximo semestre se comenzará contratar profesores para atender cursos virtuales.
Lo anterior significa que varios procesos
ocesos cambian para los mismos tipos de servicios que atienden los profesores de
planta. Es decir, se podrían reutilizar pero ajustados a la normativa y gestión de cursos virtuales.
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama de clases final del caso de estudio
Nuestro Diagrama de Clases final quedaría de la siguiente manera:
Adaptee Adapter
La Clases Adaptee (el nuevo servicio a adaptar, profesores virtuales), es referenciado (new)
( en el
adaptador.. Este hace uso de las firmas establecidas por la clase abstracta ITarget,
ITarget que incluyen el
objeto de referencia a Adaptee para insertar en cada una de estas,, tareas similares, las cuales
forman parte de los profesores virtuales con sus variaciones. Observe que el Adaptee tiene una
firma adicional a las firmas de los prof
profesores
esores de planta, la cual es implementada como parte de
la firma Servicios Varios.
Código: Caso Adapter Method
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Permite agregar dinámicamente nuevas funcionalidades a un objeto existente sin alterar o
modificar su estructura y actúa como un contenedor. Asigna responsabilidades adicionales a un
objeto dinámicamente. Este patrón proporciona una alternativa flexible a la subclase para
ampliar la funcionalidad.
Como ejemplo, tenemos un objeto profesor universitario que puede ser coordinador y
adicionalmente investigador permanente o provisional. Ahora tiene tres labores/roles
simultáneos. Pero estas responsabilidades o nuevas funciones no alteran su labor base como
profesor, solo se extienden o agregan tareas complementarias.
La Agregación que es un principio de la POO2, nos facilita que un objeto A tenga una
referencia a un objeto B y pueda delegar una tarea que el objeto B puede realizar. Recuerde
que la delegación es un mecanismo donde el ciclo de vida es autónomo tanto para el objeto A
como B, es decir, son independientes. De esta manera, es posible cambiar el comportamiento
del contenedor en tiempo de ejecución.
Ventajas
1. Puede combinar varios comportamientos envolviendo un objeto en varios decoradores.
2. Puede extender el comportamiento de un objeto sin crear una nueva subclase.
3. Principio de responsabilidad única. Puede dividir una clase monolítica que implementa
muchas variantes posibles de comportamiento en varias clases más pequeñas.
Desventajas
1. Es difícil implementar un decorador de tal manera que su comportamiento no dependa
del orden en la pila de decoradores.
Revise ahora el diagrama general de este patrón.
2
Programación Orientada a Objetos
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Los decoradores y el componente básico implementan la misma interfaz, lo que los hace
intercambiables en el código del cliente.
Observe a ahora los participantes en este patrón.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Secuencia de Clases y objetos participantes
Participante Descripción
La clase de Componente base declara operaciones comunes para ambos
ICOMPONENT BASE ( I )
componentes: objetos simple y objetos complejos.
DECORADOR BASE ( II )
Esta clase debe tener un método para hacer referencia a un objeto ajustado.
Esta clase debe declararse como una interfaz o clase abstracta y heredar del
componente base para que pueda contener tanto componentes concretos como
decoradores.
Además delega todas las operaciones al objeto envuelto (wrapper).
protected ComponenteBase _aComponente; // DI , OBJETO WRAPPER
El componente BÁSICO concreto es una clase de objetos que hace de envoltorio.
COMPONENTE BÁSICO ( III ) Define el comportamiento básico, que puede ser alterado por los decoradores, y
subsiguientes envoltorio agregados por los componentes adicionales.
Llama el objeto envuelto y altera su resultado...
Los decoradores concretos definen COMPORTAMIENTOS ADICIONALES que se
DECORADORES CONCRETO ( IV ) pueden agregar al componente base y sus antecesores de modo dinámico.
Y anulan los métodos del decorador base al ejecutar su comportamiento antes o
después de llamar al método padre/base
Trabaja con todos los objetos haciendo uso de la clase abstracta Componente
Base.
CLIENTE ( V ) y UI
Se mantiene la independencia de las clases concretas y los componentes que
trabajan con estas.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Caso de estudio: Patrón Decorator
Caso de estudio : Decorator
Requerimiento
Se desarrolla un demo genérico que el estudiante podrá ajustar.
Por ejemplo,, podría pensarse en un profesor que adopta varios roles durante el semestre.
Su rol base es profesor de planta.
El Aprendizaje Hecho Fácil!
Diagrama de clases final del caso de estudio
Nuestro Diagrama de Clases final quedaría de la siguiente man
manera:
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Código: Caso Patrón Decorator
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Este patrón se usa cuando se tienen diseños que implican estructuras en forma de árbol
jerárquico y cada nodo puede realizar una función. Se crean objetos del mismo tipo o
categoría. El patrón compuesto permite ejecutar un comportamiento de forma recursiva sobre
todos los componentes de un árbol de objetos.
El patrón compuesto (Composite) proporciona dos tipos de elementos básicos que comparten
una interfaz común: 1. hojas simples y 2. Contenedores complejos.
Un recipiente o nodo puede estar compuesto tanto de hojas como de otros contenedores. Esto
permite construir una estructura de objetos recursiva anidada que se asemeja a un árbol. Todos
los elementos definidos por el patrón compuesto comparten una interfaz común.
Ventajas
1. Puede introducir nuevos tipos de elementos en la aplicación sin romper el código
existente, que ahora funciona con el árbol de objetos.
2. Puede trabajar con estructuras de árbol complejas de manera más conveniente: use el
polimorfismo y la recursión a su favor.
Desventajas
1. Puede ser difícil proporcionar una interfaz común para clases cuya funcionalidad difiere
demasiado.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Secuencia de Clases y objetos participantes
Tenemos entonces un resumen de los participantes en este patrón así:
Participante Descripción
El contenedor (Composite) es la clase que maneja subelementos:
hojas u otros contenedores.
Un contenedor no conoce las clases concretas de sus hijos. Funciona con todos los
ICOMPONENT ( I )
subelementos solo a través de la interfaz de componentes.
Al recibir una solicitud, un contenedor delega el trabajo a sus subelementos, procesa los
resultados intermedios y luego devuelve el resultado final al cliente.
Representa los componentes complejos que pueden tener hijos (hojas, Objetos Leaf).
ICOMPOSITE ( II ) Por lo general, los objetos compuestos delegan el trabajo real a
sus hijos y luego proceden a consolidar el resultado.
La interfaz Component describe las operaciones que son comunes a los elementos
simples y complejos del árbol.
COMPOSITE CONCRETO ( III )
Puede implementar comportamientos predeterminado (tareas, métodos) o no.
Las clases concretas declaran el método que contiene el comportamiento
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
La hoja es un elemento básico de un árbol que no tiene subelementos.
HOJA (Leaf) ( IV )
Por lo general, los ccomponentes
omponentes de hoja terminan haciendo la mayor parte del trabajo
real, ya que no tienen a nadie a quien delegar el trabajo.
El código del cliente funciona con todos los componentes
CLIENTE UI ( V )
a través de la interface base
base.
Caso de estudio: Patrón Composite
Caso de estudio : Composite
Requerimiento
La escuela Norte necesita una aplicación adicional que le genere un borrador de la estructura general de un
curso: Costos, profesores, coordinación, dirección y total de estudiantes necesarios.
El Aprendizaje Hecho Fácil!
Diagrama de clases final del caso de estudio
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Código: Caso Composite
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
El patrón de diseño de Observer define una dependencia de uno a muchos entre objetos, de
modo que cuando un objeto cambia de estado, todos sus dependientes son notificados y
actualizados automáticamente, gracias al mecanismo de suscripción que permite que objetos
individuales se suscriban a notificaciones de eventos. Publisher notifica a los suscriptores
llamando al método de notificación específico en sus objetos.
1. El publicador/editor emite eventos de interés para otros objetos. Estos eventos se
producen cuando el publicador cambia su estado o ejecuta algunos comportamientos. Los
editores contienen una infraestructura de suscripción que permite que los nuevos
suscriptores se unan y los suscriptores actuales abandonen la lista.
2. Cuando se produce un nuevo evento, el publicador revisa la lista de suscripciones y llama
al método de notificación declarado en la interfaz de suscriptor en cada objeto de
suscriptor.
3. Cuando se produce un nuevo evento, el publicador revisa la lista de suscripciones y llama
al método de notificación declarado en la interfaz de suscriptor en cada objeto de
suscriptor
Ventajas
1. Puede establecer relaciones entre objetos en tiempo de ejecución.
2. Puede introducir nuevas clases de suscriptor sin tener que cambiar el código del editor.
3. Muy utilizado con código C#, especialmente en los componentes de la UI. Proporciona
una forma de reaccionar a los eventos que suceden en otros objetos sin acoplarse a sus
clases.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Secuencia de Clases y objetos participantes
Participante Descripción
Suscriptores, usuarios:
Con un método de notificación específico que recibe la notificación del
IOBSERVER ( I )
editor.
Pueden abandonar la lista del editor.
Publisher, Subject
Editor, Objeto observado.
Contiene/Ofrece los mecanismo de suscripción.
IPUBLISHER, (ISUBJECT) ( II )
Que corresponde a una lista con referencias al objeto observador
suscriber.
Sabe qué suscriptores están a la espera de notificaciones.
Suscriber
Los suscriptores concretos realizan algunas acciones en respuesta a las
notificaciones emitidas por el editor.
OBSERVADOR CONCRETO ( III )
Todas estas clases deben implementar la misma interfaz
para que el editor no esté acoplado a clases concretas.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
O Publisher : Tiene La Referencia y Control De Ciclo De Vida
Contienen una infraestructura de suscripción (Lista) que permite que los
nuevos suscriptores se unan y/o los suscriptores
res actuales abandonen la
SUJETO CONCRETO ( IV )
lista, como se observa en los parámetros del objeto List:
private List<IObserver>
> lstObservers = new List<IObserver>();
Crea
rea objetos de publicador y suscriptor por separado y, a continuación,
CLIENTE ( V ) registra a los suscriptores para las actualizaciones del publicador.
Caso de estudio: Patrón Observer
Caso de estudio : Observer
Requerimiento
La escuela Norte necesita crear un servicio para la comunidad de novedades así:
Deben crearse en el sistema los recursos y su estado (disponible, no disponible).
Habilitar el servicio de suscripciones a recursos y novedad
novedades
En el momento que el recurso (cursos creados, libros, etc.) exista o esté disponible, se informará a los
suscriptores mediante envío de correo masivo.
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama de clases final del caso de estudio
Código: Caso Observer
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Facilita el uso de una clase central context que contiene una referencia a la clase concreta tipo
estrategia, comunicándose con el objeto solo a través de la interface de la estrategia.
El patrón de diseño de la estrategia define una familia de algoritmos, encapsula cada uno y los
hace intercambiables. Este patrón permite que el algoritmo varíe independientemente de los
clientes que lo utilizan.
En otras palabras: el patrón Estrategia sugiere que tome una clase que haga algo específico de
muchas maneras diferentes y extraiga todos estos algoritmos en clases separadas
llamadas estrategias.
Ventajas
1. Puede reemplazar la herencia con la composición.
2. Puede introducir nuevas estrategias sin tener que cambiar el contexto.
3. Puede intercambiar algoritmos utilizados dentro de un objeto en tiempo de ejecución.
Desventajas
1. Los clientes deben ser conscientes de las diferencias entre las estrategias para poder
seleccionar una adecuada.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Diagrama genérico
Secuencia de Clases y objetos participantes
Participante Descripción
Clase abstracta o interface común a todas las estrategias concretas. Declara un
IESTRATEGIA ( I )
método que el contexto utiliza para ejecutar una estrategia.
Variantes del algoritmo. Presta el servicio para cada tipo de estrategia con una
clase especializada por cada uno de los tipos.
ESTRATEGIA CONCRETA ( II )
Llama al método de ejecución en el objeto de estrategia concreta cada vez
que necesita ejecutar el algoritmo.
Referencia las propiedades (métodos, get, set) que tienen la referencia al
CONTEXT ( III )
objeto estrategia.
CLIENT ( IV ) La UI que solicita el servicio para una estrategia particular.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Caso de estudio: Patrón Strategy
Caso de estudio : Strategy
Requerimiento : Pasarelas de pago
Como parte del servicio y la rapidez en los pagos, la escuela necesita que cuando una p pasarela
asarela de pago se
halle fuera de servicio o no esté disponible, el sistema de pago se encargue de ubicar otra disponible y haga la
conmutación a esta para realizar el pago.
El Aprendizaje Hecho Fácil!
Diagrama de clases final del caso de estudio
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Código: Caso Observer
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
En un sistema podrían existir un número finito de estados. Dentro de cualquier estado único, el
programa se comporta de manera diferente puede cambiar de un estado a otro
instantáneamente. Sin embargo, dependiendo del estado actual, el programa puede o no
cambiar a otros estados. Estas reglas de conmutación, llamadas transiciones que son finitas y
predeterminadas.
Así, el patrón de diseño de estado permite que un objeto altere su comportamiento cuando
cambia su estado interno.
Ventajas
1. Simplifique el código del contexto eliminando los condicionales voluminosos de la
máquina de estados.
2. Principio de responsabilidad única. Organice el código relacionado con estados
particulares en clases separadas.
Diagrama genérico
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Secuencia de Clases y objetos participantes
Participante Descripción
La interfaz de estado declara los métodos específicos del estado.
ISTATE BASE ( I ) Estos métodos deberían tener sentido para todos los estados concretos porque
no quieres que algunos de tus estados tengan métodos inútiles que nunca serán
llamados.
Proporcionan sus propias implementaciones para los métodos específicos del
Estado.
STATE CONCRETO ( II ) Los objetos de estado pueden almacenar una referencia retrospectiva al objeto
de contexto. A través de esta referencia, el estado puede obtener cualquier
información.
Almacena la referencia a uno de los objetos de estado concretos y le delega
todo el trabajo específico del estado.
El contexto se comunica con el objeto de estado a través de la interfaz de estado.
El contexto expone un configurador para pasarle un nuevo objeto de estado que
para nuestro laboratorio corresponde al siguiente método, como lo verá en el
CONTEXT ( III ) código:
public void Request()
{
Estado.CambiarEstado(this);
}
UI, que implementa las solicitudes para procesamiento dependiendo del estado
CLIENTE ( IV )
de cada una de las tareas requeridas.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Caso de estudio: Patrón State
Caso de estudio : State
Requerimiento
Se necesita un control para ir haciendo seguimiento a cada proceso de una matrícula.
Desde el:
Registro
egistro de los nuevos estudiant
estudiantes candidatos,
Verificación de documentación,
Verificación de pago,
Hasta el registro de matricula y asignación de clases.
El sistema deberá indicar el estado de cada tarea para permitir el paso a la siguiente.
El Aprendizaje Hecho Fácil!
Diagrama de clases final del caso de estudio
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Código: Caso State
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Facade es un patrón de diseño estructural que proporciona una interfaz simplificada para una
biblioteca, un marco o cualquier otro conjunto complejo de clases.
Si debemos hacer nuestro código con un conjunto amplio de objetos que pertenecen a una
biblioteca o marco sofisticado, Facade es el patrón que implementa una clase que proporciona
una interfaz simple a un subsistema complejo que contiene muchas partes móviles.
Este patrón se utiliza para ocultar las complejidades de un sistema y proporciona una interfaz
fácil de usar para el cliente al proporcionar una interfaz unificada para un conjunto de interfaces
en un subsistema.
Ventajas
1. Puede aislar su código de la complejidad de un subsistema.
Desventajas
2. La complejidad del código porque se requiere agregar un conjunto de nuevas interfaces
y clases.
Diagrama genérico
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Secuencia de Clases y objetos participantes
Participante Descripción
La fachada proporciona un acceso conveniente a una parte particular de la
FACHADA ( I ) funcionalidad del subsistema. Sabe dónde dirigir la solicitud
citud del cliente y cómo
operar todas las partes móviles.
Se puede crear una clase de fachada adicional para evitar contaminar una
sola fachada con características no relacionadas que podrían convertirla en otra
estructura compleja.
FACHADA ADICIONAL ( II )
Las fachadas adicionales pueden ser utilizadas tanto por clientes como por otras
fachadas.
El subsistema complejo consta de docenas de objetos diferentes.
Para que todos ellos hagan algo significativo, debe profundizar
profund en los detalles de
implementación del subsistema, como inicializar objetos en el orden correcto y
SUSBISTEMAS COMPLEJOS ( III ) proporcionarles datos en el formato adecuado.
Las clases de subsistema no son conscientes de la existencia de la fachada.
fachada
Operan dentro del sistema y trabajan
abajan entre sí directamente.
El cliente utiliza la fachada en lugar de llamar directamente a los objetos del
CLIENT ( IV )
subsistema.
Caso de estudio: Patrón Facade
Caso de estudio : Patrón Facade
Requerimiento
Se tiene diseñado el sistema
a que controla el proceso de matriculas, pero actualmente es bastante lento y con
una interfaz de usuario compleja.
Por tal motivo, se solicitó un proyecto para su rediseño, cuya fortaleza debe ser la automatización de procesos
asociados y suministrar una gran facilidad de uso
uso.
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
DI
Código: Caso Facade
Ir a : https://vladodotnet.wordpress.com/
El Aprendizaje Hecho Fácil!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Reafirme sus conocimientos
Llene los espacios con el concepto correcto:
Frases: Relacione el nombre del patrón que se ajusta a la afirmación:
1. nos permite generar objetos de categorías similares.
similares
2. Este patrón, permite que las subclases alteren el tipo
de objeto a crear, perm
permitiendo
itiendo que decidan que clases instanciar.
instanciar
3. Con el patrón convertimos una interface en otra,
facilitando la colaboración entre clases, ideal para clases incompatibles
incomp
por nuevas adiciones y servicios.
4. actúa como un contenedor, facilitando aplicar
nuevas
evas funcionales o características a un objeto básico/elemental
/elemental.
5. Con este patrón, , se atienden sistemas con forma de
grafos o árboles jerárquicos
jerárquicos.. Los objetos son del mismo tipo.
6. es ideal para sistemas que requieren monitorear los
cambios de estado de objetos, generando notificaciones. (Suscriptores).
7. Un sistema implementado con el algoritmo del patrón
toma una clase para realizar una tarea de muchas maneras distintas.
Controlada por una clase Context que referencia la clases del tipo de este
patrón.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño. Series desde cero. https://vladodotnet.wordpress.com/
8. Cuando usted necesite crear una UI de usuario que acceda a otros
subsistemas complejos, implemente el patrón
9. indica que nuestras clases deben ser reutilizadas sin
tener que ser reeditadas nuevamente.
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar-vallejo-vlado/
VladoDotNet – Ingeniería de software y Diseño
Diseño. Series desde cero. https://vladodotnet.wordpress.com/
Siguiente paso nivel avanzado II
Implemente su Carrito de Compras
Diseño elegante y despliegue de
información en fichas
¡Notifique al usuario!
Seguridad JWT
Proveedores externos
¡Pasarelas de pago!
Ingeniero Senior, MBA, DBA César Vallejo linkedin.com/in/cesar
linkedin.com/in/cesar-vallejo-vlado/