Tarea academica 2

Esta es una vista previa del archivo. Inicie sesión para ver el archivo original

UNIVERSIDAD NACIONAL DE LA AMAZONÍA PERUANA 
 
FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA 
 
 
 
 
 
TAREA ACADÉMICA 02 
 
 
 
 
ESTUDIANTES: FRANCO EDUARDO RODRIGUZ SILVA 
 NEDER MAYA ROJAS 
 FELIX AGUILAR BARRERA 
 EDSON EZEQUIEL ANDI JIPA 
 ALFONZO TELLO TAMANI 
 
 
 
CURSO: LENGUAJE DE PROGRAMACIÓN IV 
 
 
DOCENTE: Ing. ANGEL ALBERTO MARTHAS RUIZ 
 
 
 
 
 
 IQUITOS – PERÚ 
 
 2022 
 
 
1. ¿QUÉ FACTORES MOTIVARON LA APARICIÓN DE LOS 
PATRONES DE DISEÑO? 
1R: 
 Existen a la hora de diseñar la solución a un problema, una serie de dificultades 
que reaparecen de una manera recurrente y que eran tradicionalmente 
solucionados individualmente por cada diseñador. 
Esta manera de actuar hacía que el conocimiento no fuera compartido de una 
manera clara y exitosa, obligando a cada nuevo diseñador a reinventar la rueda 
tratando de buscar solución a problemas ya superados anteriormente por otros. 
Para paliar esta situación surgen los patrones de diseño, una forma efectiva de 
comunicar recetas exitosas probadas suficientemente como válidas para 
resolver estas dificultades. 
 La necesidad de que los diseños fuesen más reutilizables, fáciles de modificar, 
comprender y usar, más robustos y más eficientes. Esa necesidad existía y 
existe, pero no es la principal motivación. 
 La necesidad de transmitir conocimiento debido a que en el diseño la experiencia 
es muy importante y se observó que se utilizaban “recetas” para los problemas 
habituales para no estar reinventando la rueda continuamente. Por lo que 
surgieron como una forma de poder transmitir dichas recetas. 
 Te ahorran tiempo, sé que te encantará encontrar una solución ingeniosa a un 
problema cuando estás modelando tu software, y es normal, pero hay que ser 
sinceros: buscar siempre una nueva solución a los mismos problemas reduce tu 
eficacia como desarrollador, porque estás perdiendo mucho tiempo en el 
proceso. No hay que olvidar que el desarrollo de software también es una 
ingeniería, y que por tanto en muchas ocasiones habrá reglas comunes para 
solucionar problemas comunes. 
 Te ayudan a estar seguro de la validez de tu código, un poco relacionado con lo 
anterior, siempre que creamos algo nuevo nos surge la duda de si realmente 
estamos dando con la solución correcta, o si realmente habrá una respuesta 
mejor. 
Es aquí donde entra los patrones de diseño porque son estructuras probadas 
por millones de desarrolladores a lo largo de muchos años, por lo que si eliges 
el patrón adecuado para modelar el problema adecuado, puedes estar seguro 
de que va a ser una de las soluciones más válidas (si no la que más) que puedas 
encontrar. 
 Establecen un lenguaje común, Todas las demás razones palidecen ante esta. 
Modelar tu código mediante patrones te ayudará a explicar a otras personas, 
conozcan tu código o no, a entender cómo has atajado un problema. Además, 
ayudan a otros desarrolladores a comprender lo que has implementado, cómo y 
por qué, y además a descubrir rápidamente si esa era la mejor solución o no. 
Pero también te servirá para sentarte con tus compañeros a pensar sobre cómo 
solucionar algo, y poneros de acuerdo mucho más rápido, explicar de forma más 
sencilla cuáles son vuestras ideas y que el resto lo comprenda sin ningún 
problema. Los patrones de diseño os ayudarán a ti y a tu equipo, en definitiva, a 
avanzar mucho más rápido, con un código más fácil de entender para todos y 
mucho más robusto. 
2. ¿QUÉ CARACTERÍSTICA(S) DE LOS PATRONES DE 
DISEÑO FACILITAN SU REUTILIZACIÓN? 
2R. 
 Pues que suelen ofrecer soluciones a problemas recurrentes (suelen aparecer 
mucho) y estos son solucionados de una forma abstracta, por lo que "puede 
utilizarse un millón de veces sin hacer dos veces lo mismo" 
 
 Para empezar la solución descrita en los patrones de diseño es una solución 
general que ha de ser especificada para poder ser aplicada, con lo que se puede 
adaptar a muchas situaciones concretas favoreciendo así la reutilización. En 
segundo lugar, es digno de resaltar que se presenta una solución que es (o debe 
serlo) independiente de la implementación (se trata de reutilizar conocimiento 
para resolver un problema, no software). El hecho de que aparezcan reseñadas 
las consecuencias del uso del patrón (ventajas e inconvenientes) y la 
aplicabilidad (cuándo se puede usar), hace que sea posible mejorar el 
mantenimiento y facilita saber en qué situaciones el patrón ha demostrado ser 
útil para resolver un determinado problema. 
 Los patrones de diseño son un par problema/solución, por tanto, la descripción 
del problema nos ayudara a saber cuándo podemos utilizar un patrón de diseño. 
Un ejemplo concreto sería el patrón de diseño singleton, según la plantilla de 
descripción de GOF, la aplicabilidad nos dice cuando lo podemos usar. 
3. ¿CUÁL ES EL PRINCIPAL OBJETIVO DEL PATRÓN 
STRATEGY? ¿Y DEL ADAPTER? 
Strategy: Estructurar una familia de algoritmos de modo que sus clientes puedan 
intercambiarlos en tiempo de ejecución 
Adapter: Convertir la interfaz de una clase en otra interfaz esperada por los clientes. 
Permite que clases con interfaces incompatibles puedan comunicarse 
4. ¿QUÉ SITUACIONES PUEDEN MOTIVAR LA 
UTILIZACIÓN DE UN ADAPTER? 
Que la clase cliente o la que tenemos que adaptar no puedan ser modificadas, o que 
sea mas costosa la modificación de éstas que crear un adaptador 
5. ¿QUÉ RELACIÓN EXISTE ENTRE EL PATRÓN 
TEMPLATE METHOD Y EL PATRÓN STRATEGY? 
Que los dos patrones son de tipo comportamiento, ambos permiten cambiar el código. 
Mientras que el método plantilla nos permite cambiar parte del código por herencia, 
tiempo de compilación. También nos permite factorizar el comportamiento común de un 
algoritmo y así evita que tengamos que duplicar código, dejando que las extensiones se 
encarguen las subclases. 
La estrategia nos permite cambiar todo el código por composición, en tiempo de 
ejecución sin embargo tenemos que duplicar código, es posible que obliguemos a una 
subclase implementar algo que no debe y además no puedo reutilizar. 
Aunque la duplicación de código en el cliente no ocurrirá siempre, pues depende de que 
incluyamos dentro del algoritmo de la estrategia y que no. Si aplicamos estrategia a 
algoritmos que son totalmente distintos pero que solucionan el mismo problema, no 
habrá repetición de código. Con respecto a la reutilización, en estrategia se facilita la 
reutilización de los algoritmos, cosa que en template method no es posible puesto que 
obliga a que estos sean protected. La tabla resumiendo todo quedaría como sigue: 
PATRON VENTAJAS INCOVENIENTES 
 
 
EMPLATE METHOD 
 Es adecuado para 
implementar frameworks 
pues obliga a definir el 
contexto (como/cuando) 
donde se usan las distintas 
versiones en el método 
plantilla 
 Es poco flexible a los cambios 
en tiempo de ejecución 
por usar herencia 
 No permite la reutilización de 
los algoritmos (pasos en este 
caso) por definirlos como 
métodos gancho protected 
 
STRATEGY 
 Es más flexible a los 
cambios en tiempo de 
ejecución gracias a la 
utilización de delegación 
 Permite que cualquier objeto 
reutilice los algoritmos 
 No es adecuado para 
implementar frameworks 
pues no indica el contexto 
(cuando/donde) donde se 
usan los algoritmos 
 
6. ¿QUÉ SITUACIONES PUEDEN MOTIVAR LA 
UTILIZACIÓN DE UN DECORATOR? 
Cuando debido a la herencia se puede llegar a una explosión de clases, es 
decir muchos tipos de clases diferentes
que no son más que combinaciones de 
unas clases básicas con unas clases que añaden algo nuevo y además existen puntos 
de variación. 
Además deberíamos añadir aquellas situaciones donde en tiempo de compilación no se 
conocen las extensiones que necesitará un objeto. 
7. ¿QUÉ ALTERNATIVAS HAY A LA UTILIZACIÓN DE UN 
DECORATOR? 
Un Decorador consiste en la delegación, y la otra alternativa es mediante herencia.