����������������������������������������������������������������������������������

 

An�lisis comparativo de Patrones de Dise�o de Software

 

Comparative Analysis of Software Design Patterns

 

An�lise Comparativa de Padr�es de Projeto de Software

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Correspondencia: oscar.gavilanez@espoch.edu.ec

 

 

Ciencias T�cnicas y Aplicadas ���

Art�culo de Investigaci�n

��

* Recibido: 23 de mayo de 2022 *Aceptado: 12 de junio de 2022 * Publicado: 28 de julio de 2022

 

 

       I.          Ingeniero en Sistemas, Mag�ster en Interconectividad de Redes, Docente Investigador Escuela Superior Polit�cnica de Chimborazo (ESPOCH), Riobamba, Ecuador.

      II.          Ingeniera en Sistemas Inform�ticos, Mag�ster en Inform�tica Educativa, Docente Investigador Escuela Superior Polit�cnica de Chimborazo (ESPOCH), Riobamba, Ecuador.

    III.          Ingeniero en Sistemas Inform�ticos, Mag�ster en Interconectividad de Redes, Docente Investigador Escuela Superior Polit�cnica de Chimborazo (ESPOCH), Riobamba, Ecuador.

Resumen

Los patrones de dise�o brindan soluciones a problemas que se presentan durante el desarrollo de software, evitan duplicaciones de c�digo y facilitan su reutilizaci�n. En el presente art�culo se detallan la estructura, componentes, ventajas y desventajas de los patrones de dise�o: Template Method, Model-View-Controller, Model-View-Presenter, Model Front Controller y Model-View-View-Model MVVM. La investigaci�n se realiz� a trav�s de una revisi�n bibliogr�fica en bases de datos cient�ficas y consecuentemente se determinaron las m�tricas que permitieron comparar los patrones en estudio. Mediante el an�lisis comparativo de m�tricas y par�metros entre los patrones se establece que no existe un patr�n superior a nivel general, pues cada patr�n tiene su prop�sito definido y el desarrollador de software es quien debe identificar cuando un patr�n se adapta mejor a la soluci�n que desea desarrollar. Se concluye que los patrones de dise�o son estructuras bien definidas que permiten mantener una l�gica de organizaci�n en el c�digo de un sistema, gracias a esto se puede crear software de calidad, con m�s facilidad de mantenimiento y con una mejor comprensi�n del c�digo al buscar modularidad en el sistema.

Palabras Clave: Patrones de dise�o; patrones arquitect�nicos; software; modelo plantilla; MVC; MVP; controlador frontal; MVVM.

 

Abstract

Design patterns provide solutions to problems that arise during software development, avoid code duplication, and facilitate code reuse. This article details the structure, components, advantages and disadvantages of the design patterns: Template Method, Model-View-Controller, Model-View-Presenter, Model Front Controller and Model-View-View-Model MVVM. The research was carried out through a bibliographical review in scientific databases and consequently the metrics that allowed comparing the patterns under study were determined. Through the comparative analysis of metrics and parameters between the patterns, it is established that there is no superior pattern at a general level, since each pattern has its defined purpose and the software developer is the one who must identify when a pattern is best suited to the solution he wants. develop. It is concluded that design patterns are well-defined structures that allow maintaining an organization logic in the code of a system, thanks to this, quality software can be created, with easier maintenance and with a better understanding of the code when looking for modularity. in the system.

Keywords: Design patterns; architectural patterns; software; template model; MVC; MVP; front controller; MVVM.

 

Resumo

Padr�es de projeto fornecem solu��es para problemas que surgem durante o desenvolvimento de software, evitam a duplica��o de c�digo e facilitam a reutiliza��o de c�digo. Este artigo detalha a estrutura, componentes, vantagens e desvantagens dos padr�es de projeto: Template Method, Model-View-Controller, Model-View-Presenter, Model Front Controller e Model-View-View-Model MVVM. A pesquisa foi realizada por meio de revis�o bibliogr�fica em bases de dados cient�ficas e consequentemente foram determinadas as m�tricas que permitiram comparar os padr�es em estudo. Atrav�s da an�lise comparativa de m�tricas e par�metros entre os padr�es, estabelece-se que n�o existe um padr�o superior em n�vel geral, pois cada padr�o tem seu prop�sito definido e o desenvolvedor de software � quem deve identificar quando um padr�o � mais adequado para a solu��o que ele quer desenvolver. Se concluye que los patrones de dise�o son estructuras bien definidas que permiten mantener una l�gica de organizaci�n en el c�digo de un sistema, gracias a esto se puede crear software de calidad, con m�s facilidad de mantenimiento y con una mejor comprensi�n del c�digo al buscar modularidad no sistema.

Palavras-chave: Padr�es de design; padr�es arquitet�nicos; Programas; modelo de modelo; MVC; MVP; controlador frontal; MVVM.

����������������������������������������������������������������������������������������������

Introducci�n

El gran crecimiento del sector de las tecnolog�as de la informaci�n ha hecho que las pr�cticas de desarrollo de software evolucionen. Anteriormente se requer�a completar todo el software antes de realizar pruebas, lo que supon�a encontrarse con problemas. Para ahorrar tiempo y evitar volver a la etapa de desarrollo una vez que �ste ha finalizado, se introdujo una pr�ctica de prueba durante la fase de desarrollo. Esta pr�ctica se usa para identificar condiciones de error y problemas en el c�digo que pueden no ser evidentes en ese momento.

Con la llegada del desarrollo de software, los profesionales en este campo han buscado una soluci�n para disminuir la complejidad presente en el mantenimiento y organizaci�n del c�digo. A trav�s de la experiencia y el an�lisis de distintos sistemas inform�ticos se ha observado una serie repetitiva de elementos que son necesarios para el desarrollo de un sistema, al abstraer estos elementos, se da origen a los patrones de dise�o.

Un patr�n de dise�o es una t�cnica para resolver problemas simples y comunes que se encuentran en la vida diaria del desarrollo de software, sobretodo constituye una soluci�n respecto al desarrollo de interacciones o interfaces. Se puede definir un patr�n como un modelo que explica c�mo resolver un determinado problema en el desarrollo de software, no consiste en un conjunto de herramientas que se implementan en el c�digo de una aplicaci�n para resolver el problema. Un patr�n es un concepto, es el razonamiento l�gico que existe para resolver determinado problema. Aprender a implementar patrones de dise�o permite tener el conocimiento para resolver todo tipo de problemas utilizando principios del dise�o orientado a objetos.

Con el desarrollo de nuevos patrones, el abanico de posibilidades para estructurar un aplicativo se ha expandido, a tal punto de encontrarse con modelos poco usados o conocidos en la industria de desarrollo. Tener una amplia gama de patrones permite al profesional escoger aquel que mejor se adec�e a la realidad del sistema, sin embargo, se puede volver complicado comprender las peculiaridades de cada uno, dificultando su proceso de selecci�n. En definitiva, los patrones de dise�o aseguran la validez del c�digo, ya que son soluciones que funcionan y han sido probados por muchos desarrolladores siendo menos propensos a errores.

Los patrones de dise�o de software permiten afrontar proyectos de forma eficiente, puesto que ayudan a elegir opciones de dise�o que hacen que un sistema sea reutilizable, adem�s, mejoran sustancialmente el proceso de documentaci�n y mantenimiento.

El art�culo documenta un an�lisis comparativo para evaluar las caracter�sticas de cinco patrones de dise�o de software: Template Method (Modelo Plantilla), Model-View-Controller (Modelo Vista Controlador MVC), Model-View-Presenter (Modelo Vista Presentador MVP), Model Front Controller (Modelo Controlador Frontal) y Model-View-ViewModel (Modelo Vista Vista Modelo MVVM).

 

Revisi�n de la literatura

Patrones de Dise�o

Se entiende por patr�n de arquitectura de software a aquellas reglas que determinan el contexto bajo el cual se llevar� a cabo el desarrollo, estas reglas tienen comof inalidad la obtenci�n de las caracter�sticas esperadas del software en cuesti�n. Los patrones arquitect�nicos de software definen un enfoque espec�fico para el manejo de alguna caracter�stica de comportamiento del sistema [1].

Un patr�n de dise�o es una soluci�n est�ndar a un problema, los patrones de dise�o definen y organizan un vocabulario de elementos b�sicos en un conjunto de componentes y conectores de tal manera que se garanticen una adecuada composici�n de los elementos que lo conforman seg�n el esquema de organizaci�n asociado [2].

Si al querer desarrollar una aplicaci�n robusta y f�cil de mantener sabemos cumplir con ciertas reglas podemos usar patrones de dise�o que son recomendables, pero no obligatorios. Esto debido a que se establece un lenguaje com�n entre el equipo de desarrollo; los patrones de dise�o est�n ampliamente documentados y testados y ayudar�n a todo el equipo a comprender lo implementado, c�mo y por qu�.

Entre los beneficios que ofrecen los patrones se puede mencionar: reducci�n de tiempos, disminuci�n del esfuerzo de mantenimiento, aumento de la eficiencia, aseguramiento de la consistencia, aumento de la fiabilidad y protecci�n de la inversi�n en desarrollos.

Existen diferentes tipos de patrones de arquitectura cada una con sus particularidades, mismas que muchas de las veces propician el nombre a �stos, entre los m�s distinguidos se encuentran:

-        Template Method

-        Model-View-Controller MVC

-        Model-View-Presenter MVP

-        Model Front Controller

-        Model-View-View-Model MVVM

 

A)   Patr�n Template Method - Modelo Plantilla

El c�digo duplicado es el gran enemigo del �c�digo limpio�. Existe un amplio abanico de recursos para interntar eliminar este problema. Algunos patrones de dise�o tienen el objetivo de evitar que el c�digo se duplique y que se pueda aplicar buenas pr�cticas de programaci�n.

Template Method es un patr�n que define el esqueleto de un algoritmo en una operaci�n, difiriendo algunos pasos a las subclases. Template Method permite a las subclases redefinir ciertos pasos de un algoritmo sin cambiar la estructura de este [3].

Es un patr�n de dise�o de comportamiento donde se define el esqueleto de un algoritmo en la superclase, mientras que, las subclases pueden sobrescribir los pasos del algoritmo sin la necesidad de cambiar su estructura. Es un patr�n de dise�o de comportamiento donde se define el esqueleto de un algoritmo en la superclase, mientras que, las subclases pueden sobrescribir los pasos del algoritmo sin la necesidad de cambiar su estructura [4].

El objetivo del patr�n Template Method nace de la necesidad de extender determinados comportamientos dentro de un mismo algoritmo por parte de diferentes entidades. Es decir, diferentes entidades tienen un comportamiento similar pero que difiere en determinados aspectos puntuales en funci�n de la entidad concreta [2].

El patr�n Template Method tiene como objetivos [5]:

-        Proporcionar un esqueleto para un m�todo permitiendo que las subclases redefinan partes espec�ficas del m�todo.

-        Centralizar las partes de un m�todo que se definen en las subclases, pero que poseen una m�nima diferencia en cada subclase.

-        Controlar las operaciones, mismas que deben ser redefinidas en las subclases.

La figura 1 muestra los componentes que forman parte del patr�n de dise�o de comportamiento Template Method [5].

 

Figura 1. Estructura Template Method

-        Clase Abstracta: En esta clase se declaran m�todos, lo cuales act�an como pasos de un algoritmo y tambi�n el propio m�todo �templateMethod()�, el cual invoca a los otros m�todos en un orden espec�fico. Los pasos que se coloquen pueden ser declarados como abstractos o disponer de una implementaci�n por defecto.

-        Clases Concretas: Estas clases pueden sobrescribir todos los pasos declarados anteriormente en la clase abstracta, pero no el m�todo �templateMethod()�.

a) Ventajas

-        Evita duplicaci�n de c�digo: Se puede obtener un c�digo sin duplicaciones, dado que, el c�digo que var�a entre las distintas subclases permanece en cada una.

-        C�digo reutilizable: Se puede reutilizar el c�digo, ya que utiliza herencia.

-        Es f�cil de entender e implementar: El patr�n es f�cil de utilizar y adem�s proporciona un c�digo legible.

-        Flexible: Es flexible porque el patr�n permite que las subclases decidan c�mo implementar los pasos del algoritmo.

b) Desventajas

-        Comprender y depurar la secuencia de flujo del patr�n puede ser confuso, ya que puede darse el caso de que se implemente un m�todo que no deb�a implementarse, o, a su vez, no implementar un m�todo abstracto.

-        Realizar el mantenimiento del framework plantilla puede resultar dif�cil, porque al realizar cambios, ya sean, de alto o bajo nivel pueden afectar en la implementaci�n.

-        Debido a que el patr�n aplica un dise�o en particular, algunos desarrolladores pueden verse limitados a la hora de programar.

El patr�n Template Method es aconsejable en los siguientes supuestos [6]:

� Cuando se cuenta con un algoritmo aplicable a varias situaciones, cuya implementaci�n difiere �nicamente en algunos pasos.

� Arquitecturas donde los pasos de un proceso est�n definidos (el qu�), pero sea necesario establecer los detalles sobre c�mo realizarlos (el c�mo).

� M�dulos en los que exista una gran cantidad de c�digo duplicado que pueda ser factorizado en pasos comunes

 

 

B)    Model-View-Controller MVC

El MVC es un patr�n de dise�o arquitect�nico de software, que sirve para clasificar la informaci�n, la l�gica del sistema y la interfaz que se le presenta al usuario. En este tipo de arquitectura existe un sistema central o controlador que gestiona las entradas y la salida del sistema, uno o varios modelos que se encargan de buscar los datos e informaci�n necesaria y una interfaz que muestra los resultados al usuario final [7].

El patr�n Model View Controller posee los siguientes componentes [8]:

-        Modelo: este componente se encarga de manipular, gestionar y actualizar los datos. Si se utiliza una base de datos aqu� es donde se realizan las consultas, b�squedas, filtros y actualizaciones.

-        Vista: este componente se encarga de mostrarle al usuario final las pantallas, ventanas, p�ginas y formularios; el resultado de una solicitud. Desde la perspectiva del programador este componente es el que se encarga del frontend; la programaci�n de la interfaz de usuario si se trata de una aplicaci�n de escritorio, o bien, la visualizaci�n de las p�ginas web (CSS, HTML, HTML5 y Javascript).

-        Controlador: este componente se encarga de gestionar las instrucciones que se reciben, atenderlas y procesarlas. Por medio de �l se comunican el modelo y la vista: solicitando los datos necesarios; manipul�ndolos para obtener los resultados; y entreg�ndolos a la vista para que pueda mostrarlos. La figura 2 muestra la estructura del patr�n MVC

 

Figura 2. Estructura del patr�n MVC

 

 

Las ventajas y desventajas que presenta el patr�n modelo vista controlador [3] son:

a) Ventajas

-        Separa las componentes (interfaz de usuario � l�gica de negocio � acceso a datos) y permite la implementaci�n de cada uno por separado, por lo tanto, en caso de que alg�n componente falle se puede modificar f�cilmente.

-        Se puede construir varias vistas para un �nico modelo sin necesidad de modificarlo

-        Facilidad para la realizaci�n de pruebas unitarias

-        Muchos frameworks utilizan este patr�n como parte de su arquitectura.

-        Permite controlar de mejor manera los recursos del servidor, evita errores que puedan repercutir en el rendimiento.

b) Desventajas

-        Es necesario el desarrollo de una gran cantidad de clases, ya que normalmente para cada entidad se construye un controlador.

-        Su implementaci�n es dif�cil si se realiza desde un lenguaje que no es compatible con el paradigma orientado a objetos.

-        La separaci�n en capas hace que la aplicaci�n sea m�s compleja.

-        Curva de aprendizaje alta.

 

C)   Model-View-Presenter MVP

MVP es un patr�n arquitect�nico para la capa de presentaci�n de las aplicaciones software. El patr�n fue desarrollado por Taligent en la d�cada de 1990 y se implement� por primera vez en los lenguajes de programaci�n C++ y Java. MVP se basa en los principios del patr�n Modelo-Vista-Controlador (MVC) desarrollado por Xerox PARC a finales de 1970. La figura 3, muestra los componentes del MVP [10].

Figura 3. Componentes MVC

-        El modelo: es el componente que almacena los datos y la l�gica de negocio; s�lo expone un conjunto de interfaces de programaci�n para conectarse con el presentador, es decir, oculta los detalles internos de implementaci�n.

-        La vista: es la interfaz de usuario, que se encarga de recibir peticiones del usuario, las misma son transportadas al presentador para ser procesadas y finalmente el resultado es presentado por las vistas mediante interfaces de programaci�n.

-        El presentador: es el componente intermediario entre la vista y el modelo; recibe las peticiones del usuario e invoca m�todos para extraer informaci�n del modelo. A continuaci�n, obtiene el resultado y actualiza la vista.

Las ventajas del patr�n Model View Presenter [11] son:

-        Existe un bajo acoplamiento entre el modelo y la vista. Eso significa que, si el modelo o la vista se cambian, no se necesita realizar m�s modificaciones. Esto representa flexibilidad en la arquitectura.

-        El presentador ignora cualquier tecnolog�a para el dise�o detr�s de la vista, permitiendo la sustituci�n de tecnolog�as sin afectar al resto de la arquitectura.

-        La vista y el modelo pueden ser testeados de manera independiente. De manera tradicional es imposible probar la vista o el componente de l�gica de negocio de manera independiente por el acoplamiento que existe entre los dos. En consecuencia, las pruebas unitarias para la vista o el componente de l�gica de negocio son dif�ciles. Todos estos problemas se resuelven con el patr�n MVP, debido a que no hay dependencia directa entre la vista y el modelo. Por esa raz�n, el desarrollador puede utilizar un objeto falso para inyectar en la vista o el modelo para que puedan ser probados por uno mismo.

Entre las desventajas [12] se pueden mencionar:

-        Es compleja su implementaci�n, por lo tanto, es importante que el desarrollar tenga el conocimiento t�cnico.

-        No es adecuado para soluciones simples y peque�as

 

D)   Model Front Controller

El Front Controller es un patr�n de dise�o f�cil de entender en el que tiene un controlador principal que maneja cada solicitud de un sitio web. Es un patr�n de dise�o de uso com�n para muchas aplicaciones web basadas en MVC. Para usar el patr�n de controlador frontal, debe tener una sola parte de su sitio web que sea completamente responsable de manejar todas las solicitudes entrantes a su sitio/aplicaci�n. A menudo (pero no siempre) funcionar� con un sistema de enrutamiento y plantillas para devolver una respuesta relevante a la solicitud [6].

Front Controller es un patr�n de dise�o que se centra en el manejo de peticiones, usando como punto inicial un controlador que realiza la gesti�n de solicitudes, entre las gestiones que efect�a se encuentran: comprobaci�n de seguridad, manejo de errores, mapeo y delegaci�n de solicitudes a los dem�s componentes de la aplicaci�n, y as� poder trabajar en una vista adecuada para los usuarios [13].

Componentes que forman parte del patr�n de dise�o Front Controller [14]:

-        Controller: es el punto central donde se procesan y se gestionan las peticiones dentro del sistema. Existe funciones que pueden ser delegadas al asistente como: completar la autenticaci�n, iniciar la recuperaci�n de contacto o brindar autorizaciones a los usuarios.

-        Dispatcher: se encarga de gestionar la vista y navegaci�n, brindando el mecanismo para el control de la siguiente vista que se quiera mostrar.

-        Helper: ayuda al controlador y a la vista a terminar su procesamiento, poseen varias responsabilidades y pueden adaptar el modelo de datos para que la vista pueda usarla.

En la figura 4 se observa c�mo se estructura el patr�n de dise�o Front Controller.

Figura 4. Estructura del patr�n Front Controller

 

Las ventajas que presenta el patr�n Front Controller [15] son las siguientes:

-        Existe una mejora significativa en la manejabilidad de la seguridad, ya que, proporciona una barrera para controlar los intentos de acceso il�citos en la aplicaci�n.

-        Es posible reutilizar c�digo, ya que, el controlador proporciona el espacio para el particionamiento limpio de la aplicaci�n, tomando en cuenta que el c�digo entre componentes puede ser com�n.

-        Evita tener distribuida la gesti�n de peticiones, con lo cual, las aplicaciones dise�adas en base al patr�n Front Controller no ser�n categorizadas como de baja calidad.

-        No limita el n�mero de controladores en el sistema como lo hacen otros patrones.

Seg�n [16] Front Controller posee las siguientes ventajas:

� Control centralizado: el controlador frontal maneja todas las solicitudes a la aplicaci�n web. Esta implementaci�n de control centralizado que evita el uso de m�ltiples controladores es deseable para hacer cumplir las pol�ticas de toda la aplicaci�n, como el seguimiento y la seguridad de los usuarios.

� Seguridad de subprocesos: surge un nuevo objeto de comando cuando se recibe una nueva solicitud y los objetos de comando no est�n destinados a ser seguros para subprocesos. Por lo tanto, estar� seguro en las clases de comando. Aunque la seguridad no est� garantizada cuando se recopilan problemas de subprocesamiento, los c�digos que act�an con el comando siguen siendo seguros para subprocesos

Las desventajas que se describen para el patr�n Front Controller [15] son:

-        Es mucho m�s dif�cil escalar una aplicaci�n que trabaja con el patr�n de dise�o Front Controler.

-        La velocidad de respuesta disminuye al tener que ser procesadas las peticiones primero por el controlador.

-        Obliga a los desarrolladores a ver la aplicaci�n desde el mismo enfoque de los usuarios.

-        Depende de la aplicaci�n web a partir de su entorno de alojamiento.

 

E)    Model-View-ViewModel MVVM

El Patr�n Modelo Vista Vista Modelo (MVVM en sus siglas del Ingles) permite aislar limpiamente la l�gica de negocios y presentaci�n de una aplicaci�n de su interfaz de usuario (UI), permitiendo mitigar problemas de desarrollo y facilitar los procesos de prueba, mantenimiento y escalado de una aplicaci�n software. Por otro lado, permite reutilizar el c�digo, adem�s, desarrolladores y dise�adores colaboran de forma eficiente al desarrollar los respectivos m�dulos de una aplicaci�n [17].

Model View ViewModel o MVVM es un patr�n de dise�o desarrollado como alternativa al patr�n MVC. Este patr�n a diferencia de otros busca desligar a la vista del modelo con el fin de facilitar las pruebas unitarias en el sistema, manteniendo los principios generales de programaci�n modular [18].

Los componentes que forman parte del patr�n de dise�o Model View ViewModel [19] son:

-        Modelo: Es el responsable del acceso a la fuente de datos y de trabajar con esos datos.

-        Vista: Representa los datos de forma pertinente, reflejando el estado de los datos y recibiendo los eventos y las interacciones del usuario.

-        Vista del modelo: Responsable de representar la forma en que se espera que sea una vista y como se comportar� ante las interacciones que tiene con el usuario. Adem�s, describe el conjunto de principios y estructuras que presentan los datos recuperados del modelo. Como �ltimo trabajo, es el puente de comunicaci�n entre el modelo y la vista. La figura 5 muestra los componentes del patr�n de dise�o Model View ViewModel

Figura 5. Componentes patr�n de dise�o Model View ViewModel

 

Las ventajas que presenta el patr�n Model View ViewModel [20] son las siguientes:

-        Facilita el mantenimiento del sistema al mantener una alta modularidad al desligar de manera directa tanto a la vista como al modelo.

-        Disminuye la cantidad de c�digo escrito tanto en los componentes de la vista como del modelo.

-        Facilita el proceso de pruebas unitarias de cada componente al desligar a la vista del modelo completamente.

Las desventajas que se describen para el patr�n Model View ViewModel [20] son:

-        Adaptarse a una estructura predefinida puede resultar complicado sobre todo para interfaces de usuario simples.

-        La curva de aprendizaje para nuevos desarrolladores puede resultar m�s compleja que la de otros modelos m�s simples.

-        La depuraci�n del sistema puede resultar dif�cil cuando se tiene enlaces de datos complejos y un extenso n�mero de ficheros.

Metodolog�a

Para realizar el an�lisis comparativo que permiti� evaluar las caracter�sticas de los cinco patrones de dise�o de software: Template Method, Model-View-Controller MVC, Model-View-Presenter MVP, Model Front Controller y Model-View-ViewModel MVVM se desarroll� inicialmente la respectiva revisi�n bibliogr�fica, la informaci�n acerca de cada uno de los patrones fue extra�da de base de datos cient�ficas para localizar art�culos de investigaci�n, tanto de fuentes primarias como secundarias.

Se introdujeron las palabras clave �patrones de dise�o�, �patrones arquitect�nicos� y �software� en el cuadro de b�squeda para generar los art�culos sobre el tema, los art�culos resultantes generados en la lista de b�squeda se filtraron seg�n el a�o de publicaci�n y se determin� la relevancia de los resultados para el tema en cuesti�n, seleccionando 20 art�culos para la revisi�n.

Consecuentemente en base a las caracter�sticas, ventajas y desventajas de cada uno de los patrones de dise�o se determinaron m�tricas que permitan comparar los mismos.

 

Resultados y Discusi�n

Los patrones poseen ciertas caracter�sticas en com�n, Template Method es un patr�n de dise�o de comportamiento y dem�s patrones de dise�o estructural. Los patrones poseen propiedades bien definidas y tienen como prop�sito mejorar la manera de estructurar y codificar la aplicaci�n, por lo tanto, de los resultados obtenidos a pesar de las diferencias que poseen, se puede afirmar que no existe un patr�n superior a nivel general, pues cada patr�n tiene su prop�sito definido y el desarrollador de software es quien debe identificar cuando un patr�n se adapta mejor a la soluci�n que desea desarrollar. La tabla 1 muestra la comparativa entre patrones de dise�o de software.

 

Tabla 1. Comparativa entre patrones de software

 

La definici�n de par�metros para la comparativa entre patrones de dise�o se muestra en la tabla 2;� se describen a continuaci�n los par�metros:

Lenguajes de Programaci�n: Los patrones de dise�o son independientes del lenguaje de programaci�n, sin embargo, se analiza este par�metro para determinar qu� lenguajes de programaci�n son m�s comunes en la utilizaci�n de cada patr�n.

Complejidad: Permite definir cu�n complejo es el aprendizaje y utilizaci�n del patr�n de dise�o.

Seguridad: Determina el nivel de seguridad que proporciona el patr�n al dise�ar el software.

Uso: �mbito de desarrollo de software que utiliza el patr�n de dise�o

 

Tabla 2. Comparativa entre patrones de dise�o

 

Cada uno de los patrones posee caracter�sticas distintas entre par�metros, comparativa presentada permitir� a desarrolladores escoger un patr�n de dise�o seg�n sus necesidades, pues cada patr�n es fuerte en un campo distinto.

 

Conclusiones

El patr�n Template Method facilita la reutilizaci�n de c�digo, por eso es fundamental en muchos Frameworks, se vuelve de especial utilidad cuando es necesario realizar un algoritmo que sea com�n para muchas clases, pero con peque�as variaciones entre una y otras.

El patr�n Template Method es uno de los patrones m�s conocidos en el mundo de la programaci�n por su gran ayuda al momento de reescribir c�digo para reutilizarlo en un mismo proyecto, ayudando as� optimizar el tiempo del programador y agilizando procesos para brindar un software mucho m�s liviano y efectivo.

El patr�n Model-View-Controller es el m�s empleado en todo el mercado del desarrollo, adem�s, la estructura es f�cil de implementar ya que solo se maneja en los componentes vista y un controlador, adem�s, existen muchas derivaciones de este patr�n como por ejemplo MVVM, MVP entre otros. MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para modificar y comunicar los m�dulos de una aplicaci�n.

El patr�n Front Controller implementa un controlador �nico y lo usa como el punto inicial de contacto para manejar las peticiones. No es posible escalar una aplicaci�n utilizando un patr�n Front Controller.

MVP permite separar la interfaz de la l�gica en Android de forma sencilla evitando que las actividades terminen degradando en clases muy acopladas que consisten en cientos o incluso miles de l�neas. En aplicaciones grandes, es esencial organizar bien el c�digo. De lo contrario, se hace imposible mantenerlas y extenderlas. MVP consume bastante memoria debido a que depende de los atributos, adem�s, crea un atributo por cualquier necesidad.

El patr�n MVVM ayuda a separar la l�gica de las vistas de manera que se pueda tener una alta mantenibilidad en relaciones, adem�s de brindarle al programador un enfoque mayor a la l�gica en vez de programar las vistas a un nivel m�s complejo. Se recomienda utilizar este patr�n si se tiene experiencia trabajando con patrones similares como MVC, caso contrario la complejidad puede llegar a ser mayor. En MVVM no es factible la reutilizaci�n de c�digo en presencia de enlaces de datos bidireccionales.

Los patrones de dise�o son estructuras bien definidas que permiten mantener una l�gica de organizaci�n en el c�digo de un sistema, gracias a esto se puede crear software de calidad, con m�s facilidad de mantenimiento y con una mejor comprensi�n del c�digo al buscar modularidad en el sistema. �

 

Referencias

1.               Pressman, R. Ingenier�a del Software: Un enfoque pr�ctico (2010). McGrawHill.

2.               INGAR - Instituto de Desarrollo y Dise�o, M. J. Blas, H. Leone, INGAR - Instituto de Desarrollo y Dise�o, S. Gonnet, y INGAR - Instituto de Desarrollo y Dise�o, �Modelado y Verificaci�n de Patrones de Dise�o de Arquitectura de Software para Entornos de Computaci�n en la Nube�, risti, n.o 35, pp. 1-17, dic. 2019, doi: 10.17013/risti.35.1-17.

3.               E. Gamma, R. Helm, R. Johnson, y J. M. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994.

4.               A. Shvets, Sumergete en los patrones de dise�o. 2019.

5.               J. E. McDonough, �Object-Oriented Design with ABAP�, Object-Oriented Des. with ABAP, 2017.

6.               ORACLE, �Core J2EE Patterns - Front Controller�, 2022. https://www.oracle.com/java/technologies/front-controller.html

7.               A. Sunardi y Suharjito, �MVC Architecture: A Comparative Study Between Laravel Framework and Slim Framework in Freelancer Project Monitoring System Web Based�, Procedia Comput. Sci., vol. 157, pp. 134-141, ene. 2019.

8.               C. Giridhar, Learning Python design patterns : leverage the power of Python design patterns to solve real-world problems in software architecture and design. 2016.

9.               R. Jim�nez, �Utilizaci�n de la arquitectura Modelo - Vista � Controlador (MVC) en el desarrollo de una aplicaci�n web de cat�logos privados.�, Ambato, 2017.

10.            J. M. Keller, �The MVP Model: Overview and Application�, New Dir. Teach. Learn., vol. 2017, n.o 152, pp. 13-26, dic. 2017.

11.            S. Paul, A. Chatterjee, y D. Guha, �Study of Smart Inventory Management System Based on the Internet of Things (Iot)�, IJRTBT Int. J. Recent Trends Bus. Tour. |, vol. 3, n.o 3, pp. 27-34, 2019.

12.            G. Carrera y J. Germania, �An�lisis comparativo de la productividad entre los patrones de die�o Modelo Vista Controlador (MVC) y Modelo Vista Presentador (MVP) aplicado al desarrollo del Sistema N�mina de Empleados y Rol de Pagos de la Distribuidora Soria C.A.�, 2014.

13.            N. Almazova, A. Rubtsova, E. Krylova, y A. Almazova-ilyina, �BLENDED LEARNING AS THE BASIS FOR SOFTWARE DESIGN.�, 2019. [En l�nea]. Disponible en: https://go.gale.com/ps/i.do?id=GALE%7CA627003485&sid=googleScholar&v=2.1&it=r&linkaccess=abs&issn=17269679&p=AONE&sw=w&userGroupName=anon~249b91cf. [Accedido: 08-jun-2022].

14.            G. Santana Franco, �Entorno de usuario para una aplicaci�n �Fintech�: Finbook�, 2020.

15.            S. Fontan Llamas, �Construcci�n de un sitio web para KV Ingenier�a de Tecnolog�a e Infraestructuras - Archivo Digital UPM�, 2019.

16.            S. Kumar, �Front Controller Design Pattern,� Geeks for Geeks, 2020. https://www.geeksforgeeks.org/front-controller-design-pattern/.

17.            Microsoft, �El patr�n Model-View-ViewModel - Xamarin | Microsoft Docs,� 2017. https://docs.microsoft.com/es-es/xamarin/xamarin-forms/enterprise-application-patterns/mvvm

18.            G. Hurtado y H. Ramos, �Implementaci�n de sistema Web para optimizar los procesos de negocio en la empresa MN Catering S�nchez, Los Olivos - 2013�, Universidad de Ciencias y Humanidades, 2017.

19.            G. Arcos-Medina, J. Men�ndez, y J. Vallejo, �Comparative Study of Performance and Productivity of MVC and MVVM design patterns�, KnE Eng., vol. 1, n.o 2, p. 241, ene. 2018.

20.            C. Loor, �Desarrollo e implementaci�n de un sistema para la gesti�n y control de los recursos utilizados en los proyectos de investigaci�n de naturaleza estad�stica�, 2015.

 

 

 

 

 

� 2022 por los autores. Este art�culo es de acceso abierto y distribuido seg�n los t�rminos y condiciones de la licencia Creative Commons Atribuci�n-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0)

(https://creativecommons.org/licenses/by-nc-sa/4.0/).