“TERCERA UNIDAD”

TRABAJOS
UNIDAD TRES
1. Laboratorio3.- Principio de responsabilidad única.
2. TAA3.- Tres trabajos de aprendizaje autónomo.
3. TAG3.- Trabajo de aprendizaje grupal 3.
4. Foro3.- Patrones de diseño de comportamiento de template.
5. Prueba3.-Presentacion del proyecto.
6. Evaluación3.- Exposición del Proyecto.
“Laboratorio sobre principio de
responsabilidad única”
Nota: 16,5/20
Nota promediada: 2,46/3
 1. TEMA: PRINCIPIO DE RESPONSABILIDAD ÚNICA
2. OBJETIVOS:
2.1. OBJETIVO GENERAL:
Analizar y conocer el principio de responsabilidad única en la programación orientada a objetos mediante
el uso de información sobre este tema de la mano de ejercicios con los que se puedan entender correctamente
este principio de responsabilidad única para la implementación en la práctica del laboratorio.
2.2. OBJETIVOS ESPECÍFICOS:
• Identificar el concepto básico del principio de responsabilidad única mediante el uso de
fuentes confiables para ampliar el conocimiento sobre este tema.
• Comprender y desarrollar un ejemplo de la aplicación del primer principio de SOLID en las
prácticas de programación orientada a objetos.

3. DESARROLLO:
3.1. MARCO TEÓRICO
El principio de responsabilidad única es el primero del SOLID, una serie de directrices que facilitan a los
desarrolladores crear programas eficaces y entendibles. Este principio indica que una clase, debe ser
responsable de una sola cosa. (Martin, 2019)

Este principio indica si tiene mas de una responsabilidad, asume dos motivos por lo cual puede ser
modificada. (Torres, 2011)

Siempre en la presentación de programas no se puede decir esta clase hace “esto” y “esto” por que puede
ser un indicador del no uso de este principio.

3.2. DETECCIÓN DE UN MAL USO DEL PRINCIPIO

• En una clase están dos capaz de arquitectura en la clase por el estilo de programación debe
haber una capa de presentación puede ser el membrete, la lógica del motivo del programa y la de
persistencia si se mezcla estas dos puede que exista un mal uso del principio.
• Uso de métodos públicos cuando hace más de una cosa una clase, tendría varios métodos
públicos y son muy diferentes entre ellos. Es importante saber dividirlos en distintas clases.
• Los métodos de uso de los campos de la clase si existen dos campos, uno se usa en unos
métodos, otro en otros, indica que cada campo puede generar una clase independiente. Suena
confuso por que estas clases seguramente tendrían que interactuar entre sí.
• Si cuesta testear la clase si no se puede realizar el test unitario de ella o no se puede conseguir el
grado de granularidad que nos gustaría la clase se tendrá que dividir.
• Por un gran número de líneas si es demasiado grande una clase seguramente se puede dividir en
clases más manejables.
Estos pueden ser indicios, pero no son reglas. El mejor detector es la práctica. Con una buena práctica se
podrá mejorar nuestra separación en clases y el uso de que cada clase tenga un solo objetivo. (Leiva, 2016)

3.3. EJECUCIÓN Y CAPTURAS.

Primero creamos una clase Coche en donde generamos los atributos, constructores y un método que
permite guardar el coche, que es realizar una operación, pero al crear este método estamos dándole más
de una responsabilidad. Por ello está mal creado
Figura 1

Nota: Programa coche sin uso principio responsabilidad única

Luego generamos el programa principal donde ejecutamos el programa llamando a la clase coche y dándole
los objetos a ejecutar, pero está mal dado que el mismo objeto tiene también las operaciones.
Figura 2

Nota: Programa PrincipalCoche sin uso principio responsabilidad única

En cambio, si generamos la clase coche únicamente con sus atributos y métodos respectivos sin generar las
operaciones que se realizan estamos usando el principio
Figura 3

Nota: Programa Coche con uso principio responsabilidad única

Aquí colocamos el programa principal en el que se llama otro objeto de otra distinta clase por lo cual si
estamos usando la responsabilidad única.
Figura 4

Nota: Programa PrincipalCoche con uso principio responsabilidad única

Aquí podemos ver el programa del que se llama un objeto de esta en el programa principal usadso con
responsabilidad única, en el que podemos ver las operaciones la cual es guardar el coche pero y está en otra
clase de un solo propósito usando el principio
Figura 5

Nota: Programa GestionBDD con uso principio responsabilidad única este se genera al usar la
responsabilidad única generando otro programa con una sola tarea

Con este programa podemos ver que tenemos la responsabilidad única usada, dando una responsabilidad a
cada clase y permite que trabajemos mejor y eficazmente siendo cohesivo.

4. CONCLUSIONES:
• En conclusión, el principio de responsabilidad única es una herramienta indispensable para proteger
el código frente a cambios, ya que este quiere decir que un objeto debe realizar una única cosa por
lo tanto este implica que solo debería haber un motivo por el que modificar una clase.
• Al realizar el ejercicio sobre el principio de responsabilidad única comprendimos cómo usarlo y se
llegó a la conclusión que este principio funcionara de manera correcta siempre y cuando este realice
una sola cosa es decir que no se tenga varios import, ni muchos métodos públicos en la clase, ni
muchas líneas ya que quiere decir que no se esta trabajando en una sola cosa, si no que esta
involucrada en varias operaciones.
5. RECOMENDACIONES:
• Se recomienda investigar muchas fuentes bibliográficas para obtener más información sobre el
principio de responsabilidad única y así poder aplicarlo en la creación de varios programas sin
cometer errores ya que mediante la investigación y la práctica se puede dominar el tema y crear
programas de manera correcta.
• Si en un clase va incluido varios import, métodos públicos y demasiadas líneas de programación
nos esta indicando que se esta incumpliendo el principio de responsabilidad única, ya que se estaría
realizando más de una acción en el programa, por lo que se recomienda hacer una revisión del
código para detectar estos errores que se aplican generalmente en la aplicación de este principio ya
que el uso principal de este principio es facilitar la creación del código para que no se haga tan
extenso y se pueda manejar cada clase sin problemas.
 6. BIBLIOGRAFIA
Leiva, A. (2016). Principio de responsabilidad única (SOLID 1ª parte). Obtenido de devexperto:
https://devexperto.com/principio-responsabilidad-unica/

Martin, C. M. (03 de Abril de 2019). Principios SOLID. Obtenido de En mi local funciona. Technical
thoughts, stories and ideas: https://enmilocalfunciona.io/principios-solid/

Torres, J. M. (24 de Enero de 2011). Principio de responsabilidad única (I). Obtenido de

desarrolloweb.com: https://desarrolloweb.com/articulos/principio-reponsabilidad-unica-I-
dotnet.html

RESPONSABLES:

Nombres Cédula Firmas

Daniel Adrián Salazar Naupari 1755230602

Dilan Mateo Porras Pilataxi 1751610849

 Trabajos autónomos
“Tres trabajos de aprendizaje autónomo”
Nota: 85/100
Nota promedio 2,55/3
A. EVIDENCIAS DEL TRABAJO AUTÓNOMO 10:
1. TEMA: INFORME DE SOLID PRINCIPLES
2. OBJETIVOS
2.1.OBJETIVO GENERAL:
• Analizar y conocer los diferentes aspectos de los principios SOLID en la programación mediante
la cual se realiza el presente informe usando herramientas como las páginas web para adentrarse
más en el tema y tener un mejor dominio de este.
2.2.OBJETIVOS ESPECÍFICOS:
• Investigar el uso de principios SOLID en la programación orientada a objetos para comprender de
mejor manera sus fundamentos.
• Determinar cada uno de los principios SOLID y tener los conceptos claros de cada uno para que
se use de manera correcta en cada creación de programa que se lo vaya a aplicar.
3. DESARROLLO: INFORME DE SOLID PRINCIPLES
Los principios SOLID son un conjunto de principios aplicables a la programación orientada a objetos que,
si se los usa correctamente, nos ayudara a escribir software de calidad en cualquier lenguaje de
programación orientada a objetos y es gracias a estos principios que se creara códigos que será más fácil
de leer, testear y mantener.
Los principios SOLID son la base de mucha literatura que encontrarás en torno al desarrollo de software:
muchas arquitecturas se basan en ellos para proveer flexibilidad, el testing necesita confiar en ellos para
poder validar partes de código de forma independiente, y los procesos de refactorización serán mucho
más sencillos si se cumplen estas reglas. (Leiva, 2021)

Figura 1
Principios SOLID
Nota: En la siguiente imagen se puede observar cada uno de los principios SOLID, los cuales son usados
en le ambiente de la programación. Tomada de (Marco, TRIBALYTE, 2020)
A continuación, se detalla cada uno de los principios SOLID.
3.1 Principios SOLID
3.1.1 Single Responsibility
Este principio nos dice que un módulo tiene una única razón para cambiar, lo que nos quiere decir que el
principio de responsabilidad única se cumple cuando una clase solo hace una cosa.
Figura 2
Ejemplo de responsabilidad única

Nota: Este código cumple con el principio de responsabilidad única, ya que está haciendo una cosa.
Tomada de (Gustabo, 2021)
3.1.2 Open/Closed
Este principio nos dice que una entidad de software debería estar abierta a extensión, pero cerrada a
modificación. ¿Qué quiere decir esto? Que tenemos que ser capaces de extender el comportamiento de
nuestras clases sin necesidad de modificar su código. Esto nos ayuda a seguir añadiendo funcionalidad
con la seguridad de que no afectará al código existente. Nuevas funcionalidades implicarán añadir nuevas
clases y métodos, pero en general no debería suponer modificar lo que ya ha sido escrito.
Figura 3
Ejemplo del principio Abierto/Cerrado

Nota: En la imagen se muestra la clase RaceCar que extiende Car aplicando de esa manera el principio
open/close. Tomada de (Gustabo, 2021)
3.1.3 Liskov substitution
El principio de sustitución de Liskov nos dice que, si en alguna parte de nuestro código estamos usando
una clase, y esta clase es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que el
programa siga siendo válido. Esto nos obliga a asegurarnos de que cuando extendemos una clase no
estamos alterando el comportamiento de la madre. Este principio viene a desmentir la idea preconcebida
de que las clases son una forma directa de modelar la realidad.
Figura 4
Ejemplo del principio sustitución de Liskov

Nota: En la siguiente imagen se aplica el principio de sustitución. Para acelerar el auto no se necesita
conocer el tipo de clase. Tomada de (Gustabo, 2021)
3.1.4 Interface segregation
El principio de segregación de interfaces viene a decir que ninguna clase debería depender de métodos
que no usa. Por tanto, cuando creemos interfaces que definan comportamientos, es importante estar
seguros de que todas las clases que implemente esas interfaces vayan a necesitar y ser capaces de agregar
comportamientos a todos los métodos. En caso contrario, es mejor tener varias interfaces más pequeñas,
las interfaces nos ayudan a desacoplar módulos entre sí.

Figura 5
Ejemplo del principio segregación de interfaces

Nota: En la siguiente imagen se muestra un ejemplo de segregación de interfaces.

3.1.5 Dependency invertion
Este principio es una técnica básica, y será el que más presente tengas en tu día a día si quieres hacer que
tu código sea testable y mantenible. Gracias al principio de inversión de dependencias, podemos hacer
que el código que es el núcleo de nuestra aplicación no dependa de los detalles de implementación, como
pueden ser el framework que utilices, la base de datos, cómo te conectes a tu servidor. Todos estos
aspectos se especificarán mediante interfaces, y el núcleo no tendrá que conocer cuál es la
implementación real para funcionar.
Figura 6
Ejemplo del principio de inversión de dependencia.

Nota: EN la imagen se muestra un ejemplo de inversión de dependencia ya que ola clase Cash utiliza la
interfaz y desconoce su implementación. Tomada de (Gustabo, 2021)
3.2 Ventajas de los Principios SOLID
• Software más flexible, mejoran la cohesión disminuyendo el acoplamiento.
• Te van hacer entender de mejor manera las arquitecturas y para esto es necesario entender
correctamente los conceptos de los principios SOLID.
• Simplifica la creación de tests es decir si se tiene un código desacoplado y una
arquitectura, los tests van a ser mucho más sencillos.
Los principios SOLID están interrelacionados lo que quiere decir que si unos principios no pueden existir
sin los otros
4. CONCLUSIONES
• En conclusión, tener un buen conocimiento sobre los principios SOLID ayuda a tener un buen
desempeño en la programación ya que esta va a permitir tener un buen control del programa, así
mismo se puede solucionar errores de manera rápida ya que el código no se verá muy extensa y es
difícil confundirse.
• Se concluye que los principios SOLID son muy importantes para la programación ya que estos
principios van facilitando la creación del código y estos van enlazados entre ellos por lo tanto uno
se ayuda de otro ya que en una clase se puede aplicar un principio, pero la otra necesariamente va
a necesitar otra aplicación de otro principio y de ese modo el código funcionara de mejor manera
5. RECOMENDACIONES
• Al indagar sobre el tema de los principios SOLID puede resultar un poco confuso al inicio, pero si
se lo investiga más a fondo será más fácil aprender sobre estos principios por lo que se recomienda
buscar en varias fuentes bibliográficas y ver videos en YouTube para ir ampliando el conocimiento
sobre estos principios y aplicarlo en la programación.
• Se recomienda usar bien los conceptos de cada principio SOLID cuando se esté aplicando en un
programa, ya que el mal uso de estos puede generar que se incumpla uno de estos principios, por
lo tanto, realizar más programas aplicando estos principios para tener un mejor dominio del tema.
6. BIBLIOGRAFÍA

Gustabo. (12 de 03 de 2021). Home. Obtenido de Home: https://gustavopeiretti.com/principios-solid-

con-
ejemplos/#:~:text=Principios%20SOLID%20con%20ejemplos%20Que%20es%20SOLID%20en,prin
cipio%20de%20open%2Fclosed%20dice%20que%20toda%20clase%2C%20

Leiva, A. (12 de 03 de 2021). devexperto. Obtenido de devexperto: https://devexperto.com/principios-

solid/

Marco. (27 de 10 de 2020). TRIBALYTE. Obtenido de TRIBALYTE: https://tech.tribalyte.eu/blog-solid-

single-responsability

jetivo%20de%20localizar%20errores%20de%20software.
UNIVERSIDAD DE LAS FUERZAS ARMADAS “ESPE”
CARRERA DE INGENIERÍA ELECTRONICA
Y AUTOMATIZACION

Nombre: Dilan Mateo Porras Pilataxi No. Lista: 17

Asignatura: POO Período: Octubre 2021 – Febrero 2022
Fecha: 09-02-2022 NRC: 7493

B. EVIDENCIAS DEL TRABAJO AUTÓNOMO 11:

1. TEMA: MODULARIDAD
2. OBJETIVOS
2.1.OBJETIVO GENERAL:
• Analizar y comprender el modularidad en la programación orientada a objetos mediante la
realización de un informe explicando su utilidad y sus derivaciones para la comprensión de este en
la aplicación de ejercicios.
2.2.OBJETIVOS ESPECÍFICOS:
• Investigar aspectos importantes del modularidad para la comprensión del lector mediante ejemplos
que contribuyan a la investigación.
• Determinar distintos tipos de conceptos en el cual intervenga aspectos de los módulos para la
culminación del informe tomando temas influyentes en la rama de la materia.
3. DESARROLLO: MODULARIDAD
La modularidad es aquella que da la posibilidad de subdividir un sistema en varios elementos o varios
componentes para formar el sistema por completo. A menudo se cree que los archivos JAR son la unidad
de modularidad en Java, ya que cumplen con la mayoría de las características de modularidad antes
mencionadas, pero existe un problema con estos archivos, o con este concepto de módulos dentro de Java.
Y es que solo funciona o solo se cumple en tiempo de desarrollo, pero en tiempo de ejecución, pierde todo
el sentido de modularidad.
Los lenguajes soportan la modularidad de diversas formas, debe seguir los conceptos de acoplamiento y
cohesión modularizarían consiste en dividir un programa en módulos que pueden ser compilados de forma
separada, pero que tienen conexiones con otros módulos. Un módulo es una parte de algo más complejo,
este se define con palabras claves. (Lara, 2015)
Figura 1
Ejemplo de una clase y su estructura
Nota: En la imagen se muestra la conformación de la clase con sus atributos privados y métodos públicos
estrictamente necesarios. Tomada de (Harbour, 2016)
3.1 Principios de modularidad
Capacidad de descomponer un sistema complejo. Recuerdas el principio de “Divide y Vencerás”, en
este procedimiento se realiza algo similar, ya que descompones un sistema en subprogramas (recuerda
llamarlos módulos), el problema en general lo divides en problemas más pequeños.
Capacidad de componer a través de sus módulos. Indica la posibilidad de componer el programa desde
los problemas más pequeños completando y resolviendo el problema en general, particularmente cuando
se crea software se utilizan algunos módulos existentes para poder formar los que nos solicitan, estos
módulos que se integran a la aplicación deben de ser diseñados para ser reusables.
Comprensión de sistema en partes. El poder tener cada parte separada nos ayuda a la comprensión del
código y del sistema, también a la modificación del mismo, recordemos que si el sistema necesita
modificaciones y no hemos trabajado con módulos definitivamente eso será un caos.
3.2 Alta Cohesión
Un elemento tiene alta cohesión, en la medida en que tiene responsabilidades altamente relacionadas y que
no hace gran cantidad de trabajo, estos elementos pueden ser clases, subsistemas, etc.
Una clase con baja cohesión es la que hace muchas cosas no relacionadas, esto produce problemas
comunes como que son difíciles de entender, difíciles de reutilizar, difíciles de mantener, y son
constantemente afectadas por los cambios.
Alguna característica de alta cohesión es:
• Cada clase del sistema se refiere a una única entidad, es decir puede describirse con un único
nombre.
• Cada método realiza una única tarea, es decir lo que hace puede describirse con una única
frase.
Figura 2
Imagen relacionada a la alta cohesión
Nota: En la imagen se muestra un gráfico relacionado a la alta cohesión de como esta puede ser aplicada.
Tomada de (Falcon, 2019)
3.3 Bajo Acoplamiento
También se denomina conexión entre bloques. Se refiere a una medida de la cercanía entre los módulos en
una estructura de sistema de software. Cuanto más cerca están conectados los módulos, más fuerte es el
acoplamiento y peor es la independencia de los módulos. El grado de acoplamiento entre módulos depende
de la complejidad de la interfaz entre los módulos, la forma en que se llaman y la información transmitida.
Para un acoplamiento bajo, la comprensión general es un sistema completo, módulos y módulos, lo hacen
lo más independiente posible. En otras palabras, deja que cada módulo complete una subfunción de la
manera más independiente posible. La interfaz entre módulos es lo más simple posible. Si la relación entre
dos módulos es más complicada, es mejor considerar primero la división adicional del módulo, esto facilita
la modificación y la combinación. (Rubio, 2005)
Algunas características del bajo acoplamiento son:
• Las clases son lo más independientes entre sí, solo utilizan métodos y manejan objetos de un
pequeño conjunto de clases.
• Cada clase tiene una parte publica pequeña y bien definida, para usar una clase no es necesario
conocer detalles de su implementación.
Figura 3
Imagen relacionada al bajo acoplamiento
Nota: En la imagen se muestra un gráfico relacionado al bajo acoplamiento. Tomada de (Falcon, 2019)
3.4 Ventajas de un buen diseño modular
➢ La arquitectura es más sencilla.
➢ El código afectado al corregir un error o añadir una nueva funcionalidad se encuentra localizado
en unas clases.
➢ Al tener un propósito claro y ser casi independientes, es fácil reutilizar clases entre distintas
aplicaciones.
➢ Cada clase realiza un conjunto de tareas que pueden ser probadas de forma casi independiente de
las demás clases.
4. CONCLUSIONES:
• En conclusión, la modularidad es un tema del cual se usa mucho en la programación ya que detalla
al usuario que debe dividir su problema para llegar a la solución de este por eso acude a muchas
clases dándoles a cada una de ellas una tarea.
• En la modularidad intervienen muchos los dos aspectos principales que son la cohesión y el
acoplamiento bajo, aunque lógicamente se podría decir que los dos términos se relacionan, en la
programación es importante saber diferenciarlos para saber cuándo son necesarios en la división de
las clases o tareas.
5. RECOMENDACIONES
• Conocer qué importancia tiene la modularidad en la programación es vital ya que es un tema que
ayuda al usuario a resolver problemas, es un tema un poco extenso y difícil de comprender, por lo
que se recomienda investigar más a fondo este tema para ampliar su conocimiento.
• La cohesión y el acoplamiento dos clases que ayudan a resolver diversos problemas en un programa
por lo que es muy importante saber distinguirlos ya que si se llega a confundir un tema con el otro
puede acabar creando un programa no deseado.
6. BIBLIOGRAFÍA
Falcon. (01 de 02 de 2019). tech and Solve. Obtenido de tech and Solve: https://techandsolve.com/alta-
cohesion-y-bajo-acoplamiento-en-diseno-de-software/

Harbour, M. (08 de 03 de 2016). ISTR UC . Obtenido de ISTR UC: https://www.istr.unican.es/

Lara, D. (07 de 07 de 2015). Styde. Obtenido de Styde: https://styde.net/modularidad-en-la-

programacion-orientada-a-objetos/

cnoinformatic. Obtenido de tecnoinformatic: https://tecnoinformatic.com/c-programacion/patrones-de-

diseno-en-java/

Rubio, A. (07 de 02 de 2005). Prap. Obtenido de Prap: https://www.cs.upc.edu/~prap/prap/obj.pdf

 UNIVERSIDAD DE LAS FUERZAS ARMADAS “ESPE”
CARRERA DE INGENIERÍA ELECTRONICA
Y AUTOMATIZACION

Nombre: Dilan Mateo Porras Pilataxi No. Lista: 17

Asignatura: POO Período: Octubre 2021 – Febrero 2022
Fecha: 09-02-2022 NRC: 7493

C. EVIDENCIAS DEL TRABAJO AUTÓNOMO 12

1. TEMA: PATRONES DE DISEÑO
2. OBJETIVOS
2.1.OBJETIVO GENERAL:
• Describir y analizar los patrones de diseño en la programación orientada a objetos para conocer
su implementación en la materia mediante el uso de herramientas de navegación y ejemplos.
2.2.OBJETIVOS ESPECÍFICOS:
• Conocer los patrones de diseño en el uso de la programación para así poder hacer uso de este
mismo en sistemas mediante el uso de informes que hablen de este.
• Determinar los tipos de patrones de diseño para estudiarlos por separado y saber cómo aporta en
la programación orientada a objetos mediante el uso de ejemplos de cada tipo.
3. DESARROLLO: PATRONES DE DISEÑO
Los patrones de diseño fueron descritos por Christopher Alexander en el lenguaje de patrones. El libro
habla de un “lenguaje” para diseñar el entorno urbano. Las unidades de este lenguaje son los patrones.
Pueden describir lo altas que tienen que ser las ventanas, cuántos niveles debe tener un edificio, cuan
grandes deben ser las zonas verdes de un barrio, etcétera. La idea fue recogida por cuatro autores: Erich
Gamma, John Vlissides, Ralph Johnson y Richard Helm. En 1995, publicaron patrones de diseño en el que
aplicaron el concepto de los patrones de diseño a la programación. El libro presentaba 23 patrones que
resolvían varios problemas del diseño orientado a objetos y se convirtió en un éxito de ventas con rapidez.
Al tener un título tan largo en inglés, la gente empezó a llamarlo “el libro de la ‘gang of four’ (banda de los
cuatro)”, lo que pronto se abrevió a “el libro GoF”. Son soluciones habituales a problemas que ocurren con
frecuencia en el diseño de software. Son como planos prefabricados que se pueden personalizar para
resolver un problema de diseño recurrente en tu código.
A menudo los patrones se confunden con algoritmos porque ambos conceptos describen soluciones típicas
a problemas conocidos. Mientras que un algoritmo siempre define un grupo claro de acciones para lograr
un objetivo, un patrón es una descripción de más alto nivel de una solución. El código del mismo patrón
aplicado a dos programas distintos puede ser diferente. (Canelo, 2020)
La mayoría de patrones se describe con mucha formalidad para que la gente pueda reproducirlos en muchos
contextos. A continuación, se presenta las secciones que suelen estar presentes en la descripción de un
patrón:
• El propósito del patrón explica brevemente el problema y la solución.
• La motivación explica en más detalle el problema y la solución que brinda el patrón.
• La estructura de las clases muestra cada una de las partes del patrón y el modo en que se
relacionan.
• El ejemplo de código es uno de los lenguajes de programación populares facilita la asimilación de
la idea que se esconde tras el patrón.
3.1 Importancia
Los patrones ayudan a estandarizar el código, haciendo que el diseño sea más comprensible para otros
programadores. Son muy buenas herramientas y como programadores, siempre deberíamos usar las
mejores herramientas a nuestro alcance.
Evitan tener que volver a “reinventar la rueda” ante un problema que ya ha sido resuelto por otros
ingenieros. Puede que tengamos que pensar aspectos de implementación, pero la estructura del software
es la misma siempre. En segundo lugar, desde el punto de vista de la ingeniería, no podemos olvidar que
toda herramienta de ayuda es poca, y si, además, obliga a todos los desarrolladores a seguir una misma
metodología mejor todavía. Es decir, logramos uniformidad en el equipo de trabajo, obteniendo un
método de trabajo más similar entre los miembros. (Sánchez, 2017)
3.2 Tipos de patrones de diseño
Figura 1
Tipos de patrones de diseño

Nota: En la imagen se puede observar los tipos de patrones de diseño, los cuales se estudiarán con más
detalle a continuación. Tomada de (Canelo, 2020)
3.2.1 Patrones Creacionales
Los patrones de creación proporcionan diversos mecanismos de creación de objetos, que aumentan la
flexibilidad y la reutilización del código existente de una manera adecuada a la situación. Esto le da al
programa más flexibilidad para decidir que objetos deben crearse para un caso de uso dado.
Los patrones creacionales dividen en:
Abstract Factory en este patrón, una interfaz crea conjuntos o familias de objetos relacionados sin
especificar el nombre de la clase.
Figura 2
Ejemplo del patrón Abstract Factory

Nota: En la imagen se puede observar cómo debe ser implementado el patrón Abstract Factory. Tomada
de (Shvtes, 2018)
Builder Patterns Permite producir diferentes tipos y representaciones de un objeto utilizando el mismo
código de construcción. Se utiliza para la creación etapa por etapa de un objeto complejo
combinando objetos simples. La creación final de objetos depende de las etapas del proceso
creativo, pero es independiente de otros objetos.
Figura 3
Ejemplo de Builder Patterns

Nota: En la imagen se muestra como debe ser implementado el patrón Builder Patterns. Tomada de
(Parilli, 2020)
Prototype Permite copiar objetos existentes sin hacer que su código dependa de sus clases. Se
utiliza para restringir las operaciones de memoria/base de datos manteniendo la modificación al
mínimo utilizando copias de objetos.

Figura 4
Ejemplo del patrón Prototype

Nota: En la imagen se representa como debe ser implementado el patrón Prototype. Tomada de
(Parilli, 2020)
Singleton Este patrón de diseño restringe la creación de instancias de una clase a un único objeto.
Figura 5
Ejemplo del patrón Singleton

Nota: La imagen mostrada representa como debe ser implementado el patrón Singleton. Tomada de
(Canelo, 2020)
3.2.2 Patrones Estructurales
Como su nombre indica, estos patrones vienen a solucionar o facilitar las tareas de creación o
instanciación de objetos. Estos patrones hacen hincapié en el encapsulamiento de la lógica de la
instanciación ocultando los detalles concretos de cada objeto y permitiéndonos trabajar con abstracciones
Adapter se utiliza para vincular dos interfaces que no son compatibles y utilizan sus funcionalidades. El
adaptador permite que las clases trabajen juntas de otra manera que no podría al ser interfaces
incompatibles.
Figura 6
Ejemplo del patrón Adapter

Nota: Imagen que muestra cómo debe implementarse el patrón Adapter en una clase. Tomada de (Shvtes,
2018)
Brigde En este patrón hay una alteración estructural en las clases principales y de implementador
de interfaz sin tener ningún efecto entre ellas. Estas dos clases pueden desarrollarse de manera
independiente y solo se conectan utilizando una interfaz como puente.
Figura 7
Ejemplo del patrón Bridge

Nota: En la imagen se puede visualizar como es que el patrón Brigde debe ser implementado en una clase.
Tomada de (Shvtes, 2018)
Composite se usa para agrupar objetos como un solo objeto. Permite componer objetos en estructuras de
árbol y luego trabajar con estas estructuras como si fueran objetos individuales.
Figura 8
Ejemplo del patrón Composite

Nota: En la imagen se muestra la estructura que usa el patrón Bridge para poder agrupar objetos como un
solo objeto. Tomada de (Parilli, 2020)
Decorator Este patrón restringe la alteración de la estructura del objeto mientras se le agrega una
nueva funcionalidad. La clase inicial permanece inalterada mientras que una clase decorator
proporciona capacidades adicionales.
Figura 9
Ejemplo del patrón Decorator

Nota: La imagen representa como debe ser la implementación del patrón Decorator para que cumpla con
su rol. Tomada de (Parilli, 2020)
Facade proporciona una interfaz simplificada para una biblioteca, un marco o cualquier otro
conjunto complejo de clases.
Figura 10
Ejemplo del patrón Facade

Nota: La imagen muestra cómo se estructura el patrón Facade. Tomada de (Parilli, 2020)
Flyweight el patrón Flyweight se usa para reducir el uso de memoria y mejorar el rendimiento al
reducir la creación de objetos. El patrón busca objetos similares que ya existen para reutilizarlo en
lugar de crear otros nuevos que sean similares.
Figura 11
Ejemplo del patrón Flyweight

Nota: Esta imagen representa como debe ser implementado el patrón Flyweight y como es que
esta tiene su estructura. Tomada de (Parilli, 2020)
Proxy se utiliza para crear objetos que pueden representar funciones de otras clases u objetos y la
interfaz se utiliza para acceder a estas funcionalidades.
Figura 12
Ejemplo del patrón Proxy
Nota: En la imagen se observa como es el funcionamiento del patrón Proxi cuando se implementa en una
clase. (Parilli, 2020)

3.3.3 Patrones de Comportamiento

El patrón de comportamiento se ocupa de la comunicación entre objetos de clase. Se utilizan para
detectar la presencia de patrones de comunicación ya presentes y pueden manipular estos patrones.
Tratan a los objetos que manejan tipos particulares de acciones dentro de un programa. Éstos encapsulan
procesos debe ejecutarse dentro de la funcionalidad de la aplicación, como interpretar un lenguaje,
completar una petición, moverse a través de una secuencia o implementar un algoritmo. (Sanchez, 2017)
Estos patrones de diseño están específicamente relacionados con la comunicación entre objetos.
Chain of responsibility (Cadena de Responsabilidad) El patrón de diseño Chain of
Responsibility es un patrón de comportamiento que evita acoplar el emisor de una petición a su
receptor dando a más de un objeto la posibilidad de responder a una petición.
Figura 13
Ejemplo del patrón Chain of Responsibility

Nota: En la imagen se representa de que se compone el patrón Chain of Responsibility. Tomada

de (Hernández, 2016)
Command Convierte una solicitud en un objeto independiente que contiene toda la información
sobre la solicitud. Esta transformación permite parametrizar métodos con diferentes solicitudes,
retrasar o poner en cola la ejecución de una solicitud y respaldar operaciones que no se pueden
deshacer.
Figura
Ejemplo del patrón Command
Nota: En la imagen se representa como es que el patrón Command realiza su implementación.
Tomada de (Hernández, 2016)

Iterator Su utilidad es proporcionar acceso secuencial a un número de elementos presentes dentro

de un objeto de colección sin realizar ningún intercambio de información relevante.
Figura 15
Ejemplo del patrón Iterator

Nota: En la imagen se muestra al patrón Iterator y como esta debe ser implementada. Tomada de
(Hernández, 2016)
Mediator Este patrón proporciona una comunicación fácil a través de su clase que permite la
comunicación para varias clases.

’
Nota: La imagen muestra cómo se compone el patrón Mediator para realizar una comunicación
fácil a través de su clase. Tomada de (Hernández, 2016)
4. CONCLUSIONES:
• Los patrones de diseño ayudan al usuario a dar una identidad a su sistema y a resolver errores el
cual se presentan al desarrollar la idea que se plantea por ello se desfragmenta en tres aspectos de
los cuales se debe tener muy en claro para su uso.
• Los tipos de patrones de diseño son muchos y aunque en cada uno de ellos resalta uno solo se debe
tener un concepto de cada uno de ellos ya que cada uno de ellos soluciona un tipo de problema,
pero lo que más llama la atención al usuario es saber como se deben usar cada uno.
5. RECOMENDACIONES
• El aprendizaje de los patrones de diseño es un poco confuso ya que muchos de ellos se usan en la
estructuración de los programas se recomiendan al usuario consultar acerca de ello para que no
exista confusiones y que con ello conlleve errores.
 • Los subtipos de los tipos patrones de diseño tiene una manera de ayudar al usuario a resolver los
problemas, pero como usarlos y cuando usarlos depende de la imaginación y proyección de usuario
en su meta ayudarse de videos que expliquen como poder solventar estas dudas.
6. BIBLIOGRAFÍA

Canelo, M. (24 de 06 de 2020). profile. Obtenido de profile: https://profile.es/blog/patrones-de-diseno-

de-software/

Hernández, J. M. (19 de 12 de 2016). Koalite. Obtenido de Koalite:

https://blog.koalite.com/2016/12/los-patrones-de-diseno-hoy-patrones-de-comportamiento/

Parilli, M. (15 de Octubre de 2020). tecnoinformatic. Obtenido de tecnoinformatic:

https://tecnoinformatic.com/c-programacion/patrones-de-diseno-en-java/

Sánchez, M. (22 de 11 de 2017). {code}. Obtenido de {code}: https://medium.com/all-you-need-is-clean-

code/patrones-de-dise%C3%B1o-b7a99b8525e

Shvtes, A. (04 de 11 de 2018). rifactoryn. Obtenido de rifactoryn: https://refactoring.guru/es/design-

patterns/abstract-factory
“Trabajo de aprendizaje grupal 3”
Nota: 85/100
Nota Promediada: 2,55/3
 A. EVIDENCIAS DEL TRABAJO GRUPAL 3:
7. TEMA: Resolver el cuestionario de la Unidad y presentar el informe del cuestionario sobre
los temas de la Tercera unidad.
8. OBJETIVOS
8.1.OBJETIVO GENERAL:
Analizar y desarrollar el cuestionario de los temas vistos en clases mediante el uso de cortos resúmenes
para mostrar los conocimientos adquiridos durante este tiempo.

8.2.OBJETIVOS ESPECÍFICOS:
• Elaborar el cuestionario formulando preguntas con los aspectos más importantes de los temas vistos ya
en clases y guiándose correctamente de los apuntes para no poner respuestas incorrectas.
• Realizar cada pregunta del cuestionario con lógica y en base a cada tema visto, para que las
preguntas sean entendibles y no exista confusiones en el momento en que estas sean
respondidas.
• Comprender cada uno de los temas estudiados, para realizar preguntas con la información a
disposición de acuerdo a lo que corresponde a la POO.

9. DESARROLLO:
9.1. SOLID PRINCIPLES.

9.2. MODULARIDAD.

9.3. INTRODUCCIÓN A PATRONES DE DISEÑO.

Los patrones de diseño consisten en soluciones que se emplean para solventar algún tipo de error de
diseño.
Estos patrones de diseño son considerados también como una guía para poder solucionar dichos
problemas, por lo que, no se puede copiar y pegar en el código, sino que, se debe seguir una concepción
clara predefinida del patrón de diseño para resolver un problema en particular.
Según (Canelo M. M., 2020) “Los patrones de diseño son plantillas que identifican problemas en el sistema
y proporcionan soluciones apropiadas a problemas generales”, hay que aclarar que un patrón de diseño
no es lo mismo que un algoritmo para solventar un problema, ya que un algoritmo es una serie de pasos
a seguir, mientras que un patrón es una concepción o idea de cómo resolver el problema, es por eso que
el resultado de un patrón de diseño aplicado a dos programas distintos casi siempre es diferente.
Los patrones de diseño brindan al programador una especie de plano que contiene la solución del
problema, y a diferencia de un algoritmo, el programador decide como aplicar el patrón en su programa.
3.3.1. Tipos de Patrones
Los patrones de diseño se clasifican según su propósito en tres grupos los cuales son:
• Patrones creacionales
• Patrones estructurales
• Patrones de comportamiento
3.3.2. Importancia de los patrones de diseño.
Existen varias razones por las cuales un programador debería saber o dedicar tiempo al aprendizaje sobre
los patrones de diseño, una de ellas es que los patrones de diseño brindan soluciones comprobadas a
problemas de diseño que ocurren frecuentemente en el desarrollo de un programa.
Otra de la importancia que se debe saber sobre los patrones de diseño es que dichos patrones garantizan
al programador la seguridad de que el código que está desarrollando es eficaz y funciona de la mejor
manera, ya que los patrones son utilizados muy frecuentemente y es muy poco probable que se genere
algún tipo de error o problema de diseño en el código.
Preguntas
11. ¿Qué son los patrones de diseño?
A) Son códigos que son utilizados por los programadores para desarrollar un programa
B) Son técnicas o guías que sirven para solventar algunos errores de diseño que se presentan
frecuentemente en el desarrollo de un programa
C) Ninguna de las anteriores
Respuesta: B)

12. ¿Cuál es una de las ventajas que brindan los patrones de diseño?
A) Hacer que el desarrollo de un programa sea muy complicado.
B) Construir un programa complejo y muy difícil de entender.
C) La optimización del programa ya que se evitarán errores recurrentes de diseño.
D) Ninguna de las anteriores
Respuesta: C)

13. ¿Los patrones de diseño son lo mismo que algoritmos para solventar un problema?
A) Si, ya que se requiere solventar un error de diseño y se tienen que seguir una serie de procesos
para corregir dichos errores.
B) No, puesto que un patrón de diseño es una concepción para solventar un error de diseño.
Respuesta: B)

14. ¿En qué radica la principal importancia de los patrones de diseño?

A) En que los patrones de diseño brindan soluciones comprobadas a problemas de diseño que
ocurren frecuentemente en el desarrollo de un programa.
B) En que se desarrollará un programa difícil de entender y mantener.
C) En que con su aplicación se van a presentar múltiples errores de diseño.
D) Ninguna de las anteriores.
Respuesta: A)

15. ¿Cuál de estos patrones es un patrón de comportamiento?

A) Singleton
B) Prototype.
C) Adapter.
D) Strategy.
Respuesta: D)

9.4. PATRONES DE CREACIÓN.

Los patrones creacionales consisten en mecanismos que permiten la creación de objetos para incrementar
la flexibilidad y reutilización del código existente. Según (Ferrer, 2020) “Estos patrones encapsulan el
procedimiento de creación de un objeto y suelen trabajar mediante interfaces”. Es por esta razón que los
patrones creacionales le brindan más flexibilidad para decidir que objetos se deben crear dependiendo el
uso que se le vaya a dar.
Los patrones creacionales usados más frecuentemente son:
• Factory Method. – Brinda una interfaz la cual sirve para la creación de objetos que se almacenan
en una superclase.
 • Abstract Factory. – Este patrón le permite al programador crear una familia de objetos que se
relacionan entre sí, pero sin especificar las clases a las que pertenecen.
• Builder. – Este patrón le brinda al programador la posibilidad de crear distintos tipos y
representaciones de un objeto utilizando el mismo código para su construcción.
• Prototype. – Este patrón le permite al programador copiar algún objeto ya existente sin que éste
afecte al programa o depende de varias clases.
• Singleton. – Le permite al programador asignar una clase que tenga una única instancia, esto
quiere decir que este patrón restringe la creación de instancias de una clase a un solo objeto.
Preguntas
16. ¿En qué consisten los patrones de diseño creacionales?
A) Consisten en un mecanismo que permite la construcción estructurada de un programa.
B) Consisten en mecanismos que permiten la creación de objetos para incrementar la flexibilidad y
reutilización del código existente.
C) Ninguna de las anteriores
Respuesta: B)

17. ¿En qué consiste el patrón Factory Method?

A) En brindar una interfaz, la cual sirve para la creación de objetos que se almacenan en una
superclase
B) En permitir al programador crear una familia de objetos que se relacionan entre sí.
C) En brindar al programador la posibilidad de crear distintos tipos y representaciones de un objeto.
D) Ninguna de las anteriores
Respuesta: A)

18. ¿En qué consiste el patrón Builder?

A) En permitir al programador copiar algún objeto ya existente sin que éste afecte al programa o
depende de varias clases.
B) En brindar una interfaz, la cual sirve para la creación de objetos que se almacenan en una
superclase
C) En brindar al programador la posibilidad de crear distintos tipos y representaciones de un objeto.
D) Ninguna de las anteriores.
Respuesta: C)

19. ¿En qué consiste el patrón Singleton?

A) En permitir al programador copiar algún objeto ya existente sin que éste afecte al programa o
depende de varias clases.
B) En brindar una interfaz, la cual sirve para la creación de objetos que se almacenan en una
superclase.
C) En permitir al programador crear una familia de objetos que se relacionan entre sí.
D) En permitir al programador asignar una clase que tenga una única instancia.
Respuesta: D)

20. ¿En qué consiste el patrón Prototype?

A) En brindar una interfaz, la cual sirve para la creación de objetos que se almacenan en una
superclase.
B) En permitir al programador asignar una clase que tenga una única instancia..
C) En permitir al programador copiar algún objeto ya existente sin que éste afecte al programa o
depende de varias clases.
 D) Ninguna de las anteriores.
Respuesta: C)

9.5. PATRONES DE ESTRUCTURA.

Los patrones estructurales se enfocan en como las clases y objetos se componen para formar estructuras
mayores, los patrones estructurales describen como las estructuras compuestas por clases crecen para crear
nuevas funcionalidades de manera de agregar a la estructura flexibilidad y que la misma pueda cambiar en
tiempo de ejecución lo cual es imposible con una composición de clases estáticas.
Su función es determinar cómo las clases y objetos se combinan para formar estructuras. Estas permitirán
que se agreguen nuevas funcionalidades.
Los patrones GoF que se clasifican como Estructurales son:
• Composite permite componer objetos en estructuras de árbol y trabajar con esas estructuras como
si fueran objetos individuales.
• Facade proporciona una interfaz simplificada a una biblioteca, un framework o cualquiera otro
grupo complejo de clases.
• Adapter permite la colaboración entre objetos con interfaces incompatibles.
• Proxy permite proporcionar un sustituto o marcador de posición para otro objeto. Un proxy
controla el acceso al objeto original, permitiéndote hacer algo antes o después de que la solicitud
llegue al objeto original.
• Decorator permite añadir funcionalidades a objetos colocando estos objetos dentro de objetos
encapsuladores especialidades que contienen estas funcionalidades.
• Bridge permite dividir un grupo de clases estrechamente relacionadas, en dos jerarquías separadas
(abstracción e implementación) que pueden desarrollarse independientemente la una de la otra
(Díaz, 2010)
Preguntas
• Elegir la respuesta correcta
Los patrones de estructura se enfocan en….
A) Atributos y métodos
B) Objetos y interfaces
C) Objetos y clases
D) Clases y subclases
Respuesta: C
La función principal de los patrones de estructura es:
A) Determinar cómo las clases y objetos se combinan para formar estructuras
B) Especifica el comportamiento entre objetos de programa.
C) Se usa para tomar decisiones dinámicamente en el proceso de creación de objetos.
Respuesta: A
Permite proporcionar una interfaz simplificada a una biblioteca es concepto de:
D) Composite
E) Facade
F) Adapter
G) Proxy
Respuesta: B
Permite agregar nueva funcionalidad a un objeto sin modificar su estructura es concepto de:
A) Composite
 B) Bridge
C) Proxy
D) Adapter
Respuesta: D
Los patrones GoF se clasifican en:
A) Composite, decorator, facade, proxy
B) Adapter, bridge, composite, decorator, façade, flyweight, proxy
C) Proxy, facade, flyweight, composite, decorator, adapter
Respuesta: B
9.6. PATRONES DE COMPORTAMIENTO.
El patrón de diseño software de comportamiento command permite realizar una operación sobre un objeto
sin conocer realmente las instrucciones de esta operación ni el receptor real de la misma. Esto se consigue
encapsulando la petición como si fuera un objeto, con los que además se facilita la parametrización d ellos
métodos.
Aplicaciones del patrón de comportamiento command serian:
• Facilitar la parametrización de las acciones a realizar.
• Independizar los eventos de petición y ejecución.
• Dar un soporte factible a la operación deshacer.
• Desarrollar sistemas utilizando ordenes de alto nivel que se construyen con primitivas.
Los patrones de comportamiento son:
• Chain of Responsibility permite pasar solicitudes a lo largo de una cadena de manejadores. Al
recibir una solicitud, cada manejador decide si la procesa o si la pasa al siguiente manejador de la
cadena.
• Command convierte una solicitud en un objeto independiente que contiene toda la información
sobre la solicitud. Esta transformación te permite parametrizar los métodos con diferentes
solicitudes, retrasar o poner en cola la ejecución de una solicitud y soportar operaciones que no se
pueden realizar.
• Iterator permite recorrer elementos de una colección sin exponer su representación subyacente
(lista, pila, árbol, etc).
• Mediator permite reducir las dependencias caóticas entre objetos. El patrón restringe las
comunicaciones directas entre los objetos, forzándolos a colaborar únicamente a través de un
objeto mediator.
• Memento permite guardar y restaurar el estado previo de un objeto sin revelar los detalles de su
implementación.
• Observer permite definir un mecanismo de suscripción para modificar a varios objetos sobre
cualquier evento que le suceda al objeto que están observando.
• State permite a un objeto alterar su comportamiento cuando su estado interno cambia. Parece
como si el objeto cambiara su clase.
• Strategy permite definir una familia de algoritmos, colocar cada uno de ellos en una clase
separada y hacer sus objetos intercambiables.
• Template Method define el esqueleto de un algoritmo en la superclase, pero permite que las
subclases sobrescriban pasos del algoritmo sin cambiar su estructura.
• Visitor permite separar algoritmos de los objetos sobre los que operan. (Leopoldo, 2015)
Preguntas
• Elegir la respuesta correcta
Encapsula una operación en un objeto es concepto de:
 A) Command
B) Interpreter
C) Iterator
D) Mediator
E) Observer
Respuesta: A
Permite realizar recorridos sobre objetos compuestos independientemente es concepto de:
A) Memento
B) Interpreter
C) Iterator
D) Mediator
E) Command
Respuesta: C
Permite que un objeto modifique su comportamiento cada vez que cambie su estado es concepto de:
A) Command
B) Template Method
C) State
D) Observe
E) Interpreter
Respuesta: C
Define en una operación el esqueleto de un algoritmo es concepto de:
A) Memento
B) Template Method
C) State
D) Observe
E) Visitor
Respuesta: B
Permite volver a estados anteriores del sistema.
A) Strategy
B) Template Method
C) State
D) Iterator
E) Memento
Respuesta: E
4. CONCLUSIONES
• Con el desarrollo del cuestionario se pudo fortalecer los conocimientos aprendidos sobre
todos los temas contenidos en la tercera unidad, así como también se logró profundizar en
dichos temas, logrando así obtener resultados de aprendizaje favorables para nuestro
desarrollo académico.
• El cuestionario realizado se lo ha hecho con preguntas en base a los temas vistos en las clases y con
ayuda de los trabajos autónomos ya que mediante el uso de estos se pudo obtener un buen resultado
con las respuestas del cuestionario, por lo que se puede afirmar que las respuestas están contestadas
de manera correcta.
 • Se alcanzó el conocimiento deseado profundizando el contenido, para poder realizar preguntas que
respondiéndolas se aclaran dudas y se logra comprender el temario, teniendo en cuenta su uso en
los programas de estudio.
5. RECOMENDACIONES:
• Se recomienda trabajar con compañerismo y responsabilidad el trabajo grupal, ya que, con esto se
pueden tener resultados positivos de la actividad desarrollada, gracias a un buen trabajo en grupo
se pueden desarrollar habilidades para desempeñarse de una mejor manera en ambientes que se
comparta una labor, así que se recomienda prestarle la atención que corresponde y tratar de ayudar
a todos los compañeros de trabajo para un buen desarrollo de la actividad.
• Se recomienda investigar cada tema de este cuestionario más a fondo para ampliar más los
conocimientos que ya se tienen ya que siempre queda una duda y eso se puede solventar con ayuda
de páginas web o sitios donde se pueda encontrar el tema buscado.
• Releer el temario de lo visto en el parcial, realizando posibles preguntas junto a sus respuestas
fortalece la retención del contenido para realizar una mejor programación y poder llegar a
comprender toda la información de estudio.

6. BIBLIOGRAFÍA
Díaz, A. (2010, 04 12). high scalability. Retrieved from high scalability:
https://highscalability.wordpress.com/2010/04/12/patrones%C2%A0estructurales/#:~:text=Los
%20patrones%20estructurales%20se%20enfocan%20en%20como%20las,es%20imposible%20co
n%20una%20composici%C3%B3n%20de%20clases%20est%C3%A1ticas.

Leopoldo. (2015, 08 19). refactorin. Retrieved from refactorin: https://refactoring.guru/es/design-

patterns/behavioral-patterns

Ponce Hernández Jericson Steven.

Porras Pilataxi Dilan Mateo.
Salazar Naupari Daniel Adrián.
Estudiantes NRC7493
 Foro
“Sobre patrones de diseño de
comportamiento de template”
Nota: 0,7/1
 Prueba
“Presentación de proyecto”
Nota: 2,8/4
 Examen
“Exposición del proyecto”
Nota: 3,65/6
Programa ejecutado

Nombre: Dilan Mateo Porras Pilataxi

NRC: 7493