Artículo
· 23 feb, 2022 Lectura de 9 min

Implementación de patrones de proyecto utilizando el lenguaje Caché Object Script

En proyectos de software orientados a objetos son utilizados comúnmente patrones de proyecto para resolución de problemas. Si usted desarrolla en COS, este artículo tendrá sentido para su día a día.

En proyectos de software orientados a objetos son utilizados comúnmente patrones de proyectos para la resolución de problemas que pueden ocurrir con frecuencia en determinados contextos. El presente artículo aborda la implementación de patrones de proyecto utilizando el lenguaje Caché Object Script, teniendo en cuenta que existen limitaciones de la tecnología para implementaciones técnicas de programación orientada a objetos. Serán utilizados algunos de los principales patrones abordados en la literatura para comprender las dificultades encontradas para implementaciones de patrones de proyectos utilizando el lenguaje en cuestión, así como existen posibilidades de entorno para implementaciones imposibilitadas por las limitaciones del lenguaje durante el desarrollo. Por fin, destaca la capacidad del lenguaje utilizado para implementaciones complejas de proyectos de software orientados a objetos.

Palabras llave: Caché, Cache Object Script, Patrones de proyecto, programación orientada a objetos.

Introducción

Intersystems Caché es una base de datos de alto desempeño que entrega un conjunto completo de servicios para la construcción de sistemas complejos de gerenciamiento de bases de datos. Dentro de esos servicios, podemos citar el almacenamiento de datos, gerenciamiento de concurrencias, transacciones y gerenciamiento de procesos.

Dentro de Caché, los datos pueden ser modelados y almacenados como tablas, objetos o arreglos multidimensionales (jerarquías). Diferentes modelos pueden acceder a datos de forma ininterrumpida -sin la necesidad de mapeamiento de desempeño entre modelos. Soporte embutido a objetos de datos dinámicos (como XML y JSON) posibilitan fácil interoperabilidad y desarrollo rápido de aplicaciones web. (INTERSYSTEMS CACHÉ, 2019)

https://miro.medium.com/max/1152/1*hsnqDhIxdF1qDG31A-ZL5g.png

Figura 1 Arquitectura de la base de datos InterSystems Caché, por (INTERSYSTEMS CACHÉ, 2019)

Object Script es un lenguaje de programación de objetos proyectado para desarrollar rápidamente aplicaciones de negocios complejos. (INTERSYSTEMS CACHÉ, 2019)

Según la documentación, COS es un lenguaje de programación completo que ofrece recursos para manipulación de cadenas (strings), entradas y salidas, soporte para matrices espaciales y multidimensionales, soporte para SQL embarcados, comandos de direccionamiento de flujo de control dentro de un aplicativo y soporte nativo para objetos, incluyendo métodos, propiedades y polimorfismo.

Para sistemas complejos basados y proyectados con orientación a objetos, es común depararse con problemas de determinados contextos. Para la resolución de esos problemas, proyectistas de software se apoyan en la utilización de patrones de proyecto (Design Patterns).

Design Patterns (Patrones de proyecto) son patrones de modelado de software representados por principios de modelado de estructuras y códigos fuente que fueron probados diversas veces en diversos escenarios y obtuvieran éxito. (GUERRA, 2015)

Para Buschman (1996), un patrón describe una solución para un problema que ocurre con frecuencia durante el desarrollo de software, pudiendo ser considerado como un par “problema/solución”.

Según Gamma (1995), en general un patrón tiene cuatro elementos esenciales:

  1. El nombre del patrón, que es una referencia para describir un problema de proyecto, sus soluciones y consecuencias.
  2. El problema, que describe en que situación aplicar el patrón.
  3. La solución, que describe los elementos que componen el patrón de proyecto, sus relacionamientos, sus responsabilidades y colaboraciones.
  4. Las consecuencias, que son los resultados y análisis de las ventajas y desventajas de la aplicación patrón.

 

https://miro.medium.com/max/1144/1*CwrPuXFSmhIL92U6xZK1Uw.png

Figura 2 El espacio de los patrones de proyecto (Gamma, 1995)

 

Gamma (1995). Catalogó 23 patrones de diseño, conforme presentado en la figura 2, de forma de organizarlos, facilitar y aprender los patrones con mayor rapidez, así como direccionar esfuerzos en el descubrimiento de nuevos. Los patrones fueron clasificados a partir de dos criterios:

  1. Finalidad, reflectando lo que hace el patrón. Los patrones pueden tener finalidad de creación, estructural o comportamental.

Los patrones estructurales lidian con la composición de clases u objetos. Los patrones comportamentales caracterizan las formas por las cuales clases u objetos interactúan y distribuyen las responsabilidades. (GAMMA y otros, 2015).

  1. Alcance, especificando si el patrón se aplica primariamente a clases o a objetos.

Los patrones para clases lidian con los relacionamientos entre clases y subclases. Esos relacionamientos son establecidos a través del mecanismo de herencia, así ellos son estáticos -fijados en tiempo de compilación. Los patrones para objetos lidian con el relacionamiento entre objetos que pueden ser alterados en tiempo de ejecución y son más dinámicos. Casi todos utilizan la herencia en cierta medida. (GAMMA y otros, 2015).

El presente artículo tiene como objetivo implementar patrones de proyecto en el lenguaje COS y verificar si la tecnología soporta implementaciones basadas en patrones para resolución de problemas.

Con la búsqueda, será posible identificar posibles limitaciones y fuerzas de lenguaje para las implementaciones de proyectos de software complejo. Para tal, serán utilizados algunos patrones con complejidad de implementación más baja clasificados con la finalidad de creación, estructural y de alcance de clases y de objetos.

Los patrones utilizados están descritos abajo, así como una breve descripción según Gamma (1995):

  1. Factory Method, define una interface para crear un objeto, pero deja que las subclases decidan cual será instanciada. El Factory Method permite a una clase postergar (aplazar) la instanciación de las subclases.
  2. Builder, separa la construcción de un objeto complejo de su representación, de modo que el mismo proceso de construcción pueda crear diferentes representaciones.
  3. Prototype, especifica los tipos de objetos a ser creados usando una instancia prototípica y crea nuevos objetos copiando ese prototipo.
  4. Singleton, garantiza que una clase tenga solamente una instancia y proporciona un punto global para su acceso.
  5. Facade, proporciona una interface unificada para un conjunto de interfaces en un subsistema. Facade define una interface de nivel mas alto que vuelve el subsistema más fácil de usar.

Desarrollo

 La práctica utilizó la versión 2018.1.3 de Caché, implementando y evaluando los patrones de proyectos en los siguientes tópicos utilizando el lenguaje de programación COS.

  1. Factory Method

Las clases abajo ejemplifican la utilización del patrón Factory Method para tratar un problema de negocio relacionado en que es necesario especificar el tipo de ejecución que es lanzada. Fueron definidos tres tipos de excepciones: de negocio, inesperada y no tratada.

https://miro.medium.com/max/1400/1*J86_RbJkHYJFaeCPiQSnlQ.png

Figura 3 Implementación de la clase excecao.ExcecaoFactory (por el autor)

La figura 3 demuestra la implementación de la clase excecao.ExcecaoFactory, que efectivamente implementa el patrón. El método GetObjetoExcecao(), creado en la línea 6, recibe la instancia de un objeto de tipo AbstractException y con base en las implementaciones de los métodos auxiliares, decide cual objeto debe ser retornado de acuerdo con el tipo.

Las figuras 4, 5 y 6, representan la implementación básica de las clases para cada tipo de excepción utilizada en el ejemplo.

https://miro.medium.com/max/1400/1*C2EJc0_7wwC7Edr1V4DQOg.png

Figura 4 Implementación de la clase excecao.ExcecaoNegocio (por el autor)

 

https://miro.medium.com/max/1400/1*dgd5CabSJiW38M0J74z_Kg.png

Figura 5 Implementación de la clase excecao.ExcecaoInesperada (por el autor)

 

https://miro.medium.com/max/1400/1*4fh6gUHTKlYKFF93DHIk-Q.png

Figura 6 Implementación de la clase excecao.ExcecaoNaoTratada (por el autor)

 

  1. Builder

Para la implementación del patrón Builder, fue utilizada la entidad Pessoa Jurídica como base. Esa entidad, de forma simple, es compuesta por las propiedades Razão Social, Nome Fantasia y Cnpj. La implementación de la clase puede ser analizada en la figura 7 abajo:

https://miro.medium.com/max/1400/1*DqDu008Rol3wWa645Fzt7A.png

Figura 7 Implementación de la clase builder.PessoaJuridica (por el autor)

 

La implementación del patrón Builder, demostrado en la figura 8, define una propiedad de clase de tipo builder.PessoaJuridica, que es utilizada para almacenar las informaciones que son definidas para el objeto y para la clase utilizada en el Builder. Los métodos setters, creados en las líneas 21, 28 y 35, reciben un valor por parámetro y hacen el set en la propiedad de la clase y luego retornan la instancia del objeto. Ese retorno es necesario para que, en la utilización de la clase, demostrado en la figura 9, sea posible hacer llamadas a los métodos setter de forma funcional y secuencial, siendo posible en una única línea definir el objeto que es requerido al patrón de forma simple.

 

https://miro.medium.com/max/1400/1*2aSefCvPneU9uNBm81ZibA.png

Figura 8 Implementación de la clase builder.PessoaJuridicaBuilder (por el autor)

 

https://miro.medium.com/max/1400/1*GJYuE299Ji-E72JlENT31Q.png

Figura 9 Ejemplo de utilización del patrón builder (por el autor)

 

 

  1. Protoype

La clase prototype.CasaPrototype, presentada en la figura 10 abajo, implementa el patrón prototype creando el método abstracto getPrototipe() en la línea 6:

https://miro.medium.com/max/1400/1*pZlrRSJmwwpqmxHLolXNmg.png

Figura 10 Implementación de la clase prototype.CasaPrototype (pelo autor)

 

Las figuras 11 y 12 presentan la implementación de las clases prototype.SimplesPrototype e prototype.SobradoPrototype, ambas heredando la clase prototype.CasaPrototype. En las dos clases el método getPrototype() es implementado retornando una nueva instancia de si mismo, una copia del objeto prototipado.

 

https://miro.medium.com/max/1400/1*_qyU1ksXzjQtf0_nbKxSnQ.png

Figura 11 Implementación de la clase prototype.SimplesPrototype

https://miro.medium.com/max/1400/1*OYVCL9qWzfg_hYz_bKNnTw.png

Figura 12 Implementación de la clase prototype.SobradoProtoype (por el autor)

 

  1. Singleton

El patrón Singleton permite la creación de objetos únicos y con apenas una instancia, ofreciendo un punto de acceso global dentro de la aplicación. Con eso, el patrón tiene como definición garantizar que una clase tenga apenas una instancia de sí y que exista solamente un punto global de acceso, gerenciando la propia instancia y evitando que cualquier clase cree una instancia de ella. De esta forma, ninguna otra clase puede instanciarla además de ella misma.

 

Como ejemplo, desarrollando en el lenguaje Java y utilizando el modificador synchronized garantiza que el patrón sea implementado, impidiendo que dos instancias de la clase sean creadas. En COS, ese modificador no existe.

 

Para acceso global utilizando COS, puede accederse directamente a las globales de la base, pero no es posible guardar instancias de objetos en globales.

 

Por presentar las limitaciones mencionadas arriba, no fue posible implementar el patrón Singleton en el lenguaje COS.

 

  1. Facade

El patrón Facade tiene la intención de simplificar la utilización de subsistemas complejos implementando una interface única y razonable.

https://miro.medium.com/max/1400/1*hbfl7qGG304pOGFbj3dcrg.png

Figura 13 Implementación de la clase facade.SistemasFacade (por el autor)

 

En la imagen 13, la clase facade.SistemasFacade implementa el patrón creando una interfaz única para la utilización de sistemas de audio e imagen. El constructor instancia los objetos de las dos clases y ejecuta los métodos para definir las configuraciones necesarias. Para las clases que la utilizan, están expuestos los métodos para reproducción de video y audio, unificados y simplificados en una única clase.

Análisis de los resultados

Los resultados encontrados con las búsquedas se mostraron satisfactorios. Algunas dificultades fueron encontradas por falta de algunos modificadores para definiciones de alcance global, como interfaces. Además de los modificadores, técnicas como la sobrecarga de métodos no fueron posibles de ser utilizados por las limitaciones del lenguaje. Sin embargo, el desarrollo en el lenguaje COS es simple, lo que vuelve el trabajo y organización de las clases productiva.

Conclusiones

Es posible afirmar que, para la mayoría de los patrones catalogados, el lenguaje COS ofrece los recursos necesarios para la implementación orientada a objetos.

Comentarios (0)0
Inicie sesión o regístrese para continuar