Desarrollo Multilenguaje con Patrones de Diseño

en la plataforma .NET
León E. Welicki,
Fernando Cano García
Universidad Pontificia de Salamanca, campus de Madrid
Departamento de Lenguajes, Sistemas informáticos e Ingeniería del Software
España, Madrid, Majadahona, c/Sorolla 4, 28220

Resumen. La posibilidad de interacción de componentes de código escritos en

diversos lenguajes es una característica muy promocionada del framework
.NET. Dado que todos los lenguajes compilan a un lenguaje intermedio, el
MSIL, todos son “de primera clase”, lo cual idealmente acota la elección del
lenguaje a preferencias sintácticas. Si bien el lenguaje con más apoyo de
Microsoft dentro del entorno .NET es C#, existe una amplia base de
desarrolladores y código Visual Basic funcionando actualmente en las
empresas. Existe también una gran base de código COBOL, del cual quizás no
hay documentación y forma parte de un “bloque atómico de funcionalidad”.
Utilizando programación multilenguaje en .NET podríamos unir bloques de
código heredado (con pequeñas modificaciones de adaptación) y nuevas
aplicaciones en la plataforma .NET. Como veremos, si esta tarea se realiza en
forma ad-hoc puede ser sumamente compleja e introducir altos volúmenes de
entropía en un nuevo desarrollo.

Para poder instrumentar esto en forma eficiente, proponemos en este trabajo la

utilización de los patrones de diseño del GoF, técnica que nos permitirá obtener
los beneficios del código multilenguaje a partir de un diseño orientado a
objetos basado en soluciones ampliamente aceptadas por la industria. Con
respecto al entorno .NET, Microsoft ha demostrado un claro interés en los
patrones de diseño en las sesiones presentadas en su último Tour de
Arquitectos Corporativos Europeos de Microsoft (EMEA Tour).

Palabras clave: Patrones de Diseño, .NET, Programación multilenguaje,

Ingeniería del Software, Orientación a Objetos

1. Introducción
La idea de abstracción del lenguaje de programación no es nueva. Es algo que se ha
intentado a lo largo de los años con las distintas tecnologías basadas en objetos y
componentes. Dentro del mundo COM (Component Object Model), un cliente COM
escrito en Visual Basic podía invocar a otro escrito en Visual C++. Esta relación no
estaba restringida sólo a estos dos entornos: cualquier componente que
implementase la especificación COM (un conjunto determinado de interfases)
podría interactuar con otro similar. Esto se hace también extensible al mundo
DCOM, donde el lenguaje no era el punto determinante sino la implementación de
una especificación en forma de un conjunto determinado de interfaces (en breve,
profundizaremos sobre este punto).

1.1 Antecedentes del Problema

1.1.1 Clases de lenguajes

De todos modos, si bien los componentes escritos en diferentes lenguajes podían
interoperar era muy probable que internamente no tuviesen las mismas
características: en la jerga, podía decirse que existían “lenguajes de primera” y
“lenguajes de segunda”. Esta categorización estaba determinada por las
características del lenguaje: Visual Basic tenía funcionalidades mucho más acotadas
que C++ (de hecho mucha gente lo consideraba despectivamente un lenguaje de
juguete a pesar de tener más de 6 millones de usuarios). Consecuentemente, existían
una serie de tareas que no se podían hacer directamente dentro de componente
escrito en Visual Basic. La solución en ese caso era hurgar en el API de Windows en
busca de las funcionalidades necesarias o desarrollar la funcionalidad problemática
en Visual C++ (o algún lenguaje con potencia similar basado en COM).

1.1.2 Interoperabilidad en COM

La posibilidad de combinar código a través de componentes COM abría un mundo

de posibilidades a la ingeniería del software en ambientes Windows, tales como
reusabilidad, abstracción (parcial) del lenguaje de programación, mayor velocidad
de desarrollo de aplicaciones basándose en componentes existentes.

De todos modos, al momento de combinar código (mediante interfaces COM)

escrito en diversos lenguajes surgían problemas tales como la incompatibilidad de
tipos (cada entorno mantiene su propio sistema de tipos y la conversión es muy
costosa y es una gran fuente de errores), los problemas de manejos de versiones (el
dll hell tan citado por Dan Appleman en [4]), mal manejo de la memoria y los
distintos modelos de threading (Visual Basic 6 no soporta el modelo multithreaded,
como mucho brinda el modelo de threading apartment).

Además, no todos los lenguajes soportaban las mismas características de orientación

a objetos: tomando como extremos a Visual Basic 6.0 y a Visual C++, sus
características respecto a orientación a objetos estaban a años luz de distancia.

2. Arquitectura de .NET
A continuación, intentaremos explicar en un párrafo, en forma resumida, los
conceptos principales de la arquitectura de .NET en lo concerniente a la compilación
multilenguaje, a efectos de establecer las bases para nuestro posterior análisis.

2.1 Compilación y ejecución

La base del .NET es el Common Lenguaje Runtime, que es la maquina virtual de

.NET. El CLR es quien ejecuta el código administrado que se genera con los
distintos lenguajes de .NET. Cuando se compila el código escrito en cualquier
lenguaje, se obtiene como resultado un código intermedio llamado MSIL (Microsoft
Intermediate Lenguaje), el cual es interpretado y ejecutado por el CLR. Todos los
lenguajes generan este código, con lo cual el lenguaje de origen del código MSIL es
absolutamente transparente para el CLR. De esta manera, todos los lenguajes
comparten el mismo sistema de tipos, que es el sistema de tipos sobre el que se basa
el MSIL. Al momento de ejecutar código de máquina específico de la plataforma,
entra en escena el compilador just-in-time (JIT), que es quien finalmente genera el
código de máquina específico que se ejecutará en un entorno determinado
(actualmente, hay versiones para Windows y Linux [12]). Este proceso está ilustrado
en la figura 1, a continuación.

Herramienta de
desarrollo, como Compilador just-in-
Visual Studio .NET. time (JIT)

Código Fuente Microsoft Código

(Visual Basic.NET, Intermediate especializado para
Visual C++.NET, Languaje la plataforma
C#, COBOL, etc.) (MSIL) (Windows, Linux)

Figura 1 –Esquema de compilación multilenguaje del entorno .NET

2.2 Consecuencia: Todos los lenguajes son primera clase

En el framework .NET, todos los lenguajes son primera clase. Esto significa que
cualquier tarea puede ser realizada con cualquier lenguaje, lo cual limita la elección
del mismo a preferencias sintácticas (y podría decirse que políticas, ya que la mayor
parte de los samples están en C#, y así también ciertas herramientas, como por
ejemplo NDoc).

Esto es posible debido a las siguientes características del entorno .NET:

• Todos los lenguajes se compilan a un código intermedio, el MSIL, que es
interpretado por el Common Lenguaje Runtime (CLR, la máquina virtual
de .NET)
• Todos los lenguajes comparten el sistema de tipos unificado. Además de
ser fuertemente tipado, .NET comparte su sistema de tipos entre todos sus
lenguajes
• Todos los lenguajes comparten las mismas características de orientación a
objetos
• Todos los lenguajes pueden utilizar los objetos del framework .NET en la
misma forma
• Los lenguajes se mapean a un modelo de objetos .NET. Las clases no
precisan revelar su lenguaje de origen (Meyer, [6])
Todos estos beneficios se aplican al código administrado, que es el código que se
ejecuta en el CLR.

3. Programación Multilenguaje
Según Bertrand Meyer, “la habilidad para mezclar lenguajes ofrece grandes
promesas para el futuro de los lenguajes de programación”. La programación
multilenguajes, como está planteada en .NET, presenta un amplio conjunto de
beneficios a la ingeniería del software, pero también trae consigo otro conjunto de
amenazas. A continuación, exploraremos estos dos puntos.

3.1 Beneficios
3.1.1 Integración de aplicaciones legadas (Legacy)

Muchos sistemas o componentes pueden ser aprovechados realizando pequeñas

modificaciones en su código. Esta categoría incluye a los sistemas legados (como
los que nos podemos encontrar en muchas entidades financieras) o el catálogo de
componentes extraídos de la experiencia acumulada en los proyectos que hemos
participado.

La compatibilidad entre lenguajes facilita esta tarea, ya que las funcionalidades

básicas migradas escritas en un lenguaje (por ejemplo, COBOL) pueden luego ser
heredadas y extendidas por clases escritas en otro (por ejemplo, C#).

3.1.2 Facilidad de migración de bloques concretos de código.

Determinados bloques de código heredado pueden ser reaprovechados utilizando la

característica multilenguaje de la plataforma .NET. De todas formas, en todos los
casos será necesario un proceso de migración. Sin embargo, en algunos casos
podemos encontrarnos con la ventaja de que la traducción no requiere tanto esfuerzo
(en otros, es literalmente imposible).

Existen casos donde la sintaxis es muy similar, incluso ciertos elementos se podrían
automatizar de una manera muy sencilla. La diferencia radica principalmente en la
utilización de objetos del framework en lugar de APIs específicas del sistema
operativo.

3.1.3 Poder aprovechar las ventajas de cada lenguaje.

Aprovechar lo mejor de cada lenguaje para el desarrollo del software es también una
idea atrayente: COBOL para modelar procesos batch, C++ para calculo numérico o
funciones no manejadas, Visual Basic para acceso a BBDD, Eiffel para situaciones
donde precisemos utilizar herencia múltiple, et...

Mediante de un diseño adecuado podemos adaptar componentes escritos en cada

uno de estos lenguajes con grados de dificultad relativamente pequeños.

Es fundamental tener en cuenta que la información de la aplicación no reside sólo en

el código sino en el análisis y en el diseño, los cuales deben estar a un nivel de
abstracción suficiente para tener constantemente el control de lo que se está
haciendo.

3.1.4 Aprovechar las habilidades y preferencias de cada programador.

Cada integrante del equipo de desarrollo puede potencialmente aportar más si no

está limitado a un lenguaje de programación fijo. Es normal que cada desarrollador
conozca más de un lenguaje de programación. Indudablemente será más experto en
uno que en otro.
Adoptando la filosofía propuesta, podemos hacer que el desarrollador tenga
flexibilidad a la hora de programar, siempre que cumpla con las premisas que
especifica el diseño.

3.1.5 ¡La clave, es la orientación a objetos!

Las bases de los lenguajes OO son siempre las mismas: los conceptos de clase,
interfaz, método, atributo, permanecen invariables a lo largo de los distintos
entornos

Lo que realmente cambia es el modo de expresarlo, incluso muchas veces la

sustitución de una palabra clave puede ser suficiente para pasar a otro lenguaje. Lo
que distingue de un lenguaje a otro son las facilidades que proporciona para realizar
un determinado proceso, operación, tratamiento de errores, documentación o
comunicaciones con otros dispositivos y éste debe ser el motivo por el cual elegir
uno en lugar del otro.

3.2 Potenciales problemas de la programación multilenguaje

Si bien la programación multilenguaje aporta muchos beneficios, también tiene su

lado malo: si no está bien regulada y no se parte de un diseño apropiado, cualquier
equipo puede salirse de control inmediatamente. Esto puede provocar que se creen
aplicaciones muy difíciles de mantener, donde no exista nadie que tenga un
conocimiento someramente global de la aplicación. Todo esto puede confluir en una
especie de anarquía, cuyo resultado final es un producto de software de baja calidad
y con altos niveles de entropía en su nacimiento (es muy interesante al respecto de la
entropía en el software la reflexión de Ivar Jacobson en [7]).

El ideal utópico en que cada equipo desarrolle en su lenguaje favorito o se utiliza un

lenguaje para migración de un bloque de código determinado sólo puede ser
sostenido por un diseño apropiado, donde el lenguaje sea realmente sólo una
elección sintáctica.

4. Patrones de Diseño
En esta sección definiremos brevemente el concepto de patrones y como encajan en
la estrategia de arquitectura de Microsoft (para más información sobre estos temas,
ver [1], [13] y [14]). Finalmente, explicaremos por qué los patrones de diseño son
una gran opción para el desarrollo multilenguaje.

4.1 Definición

Los patrones de diseño fueron definidos originalmente por Christopher Alexander en

su libro “A Pattern Language” publicado por MIT Press en 1977. En ese caso,
estaban enfocados a construcción de edificios y no de software. En dicha obra, se
define a los patrones en la siguiente forma:
 “Cada patrón describe un problema que ocurre una y otra vez en nuestro
entorno, así como la solución de ese problema, de tal modo que se pueda
aplicar esa solución un millón de veces, sin hacer lo mismo dos veces”,
Christopher Alexander, citado en [1]

La idea fundamental detrás de los patrones de diseño es reutilizar buenas prácticas

de diseño en forma eficiente. Fueron popularizad por el GoF (Gang of Tour o Banda
de Cuatro, conformada por Gamma, Helm, Johnson, y Vlissides) en su obra “Design
Patterns: elements of reusable software” ([1]), en 1995. En dicha obra se definen 23
patrones, los cuales se dividen en 3 grupos:
• Patrones Creacionales: inicialización y configuración de clases y objetos
[15]
• Patrones Estructurales: desacoplar la interfaces y la implementación de
clases y objetos [15].
• Patrones de Comportamiento: manejar las interacciones dinámicas en un
ecosistema de clases y objetos [15].

4.2 Los patrones de diseño en la estrategia de arquitectura de Microsoft.

Los patrones de diseño están comenzando a ocupar un espacio fundamental en las

estrategias y arquitecturas planteadas por Microsoft. En las últimas conferencias del
EMEA Tour (European Microsoft Enterprise Architects Tour), este mensaje ha sido
difundido en forma muy clara: hubieron varios tracks dedicados específicamente a la
utilización de patrones de diseño (Patrones para Sistemas Concurrentes y
Conectados en Red y Diseñando un marco arquitectónico para Interoperabilidad
entre otros).

Además de estás charlas específicas, los patrones estuvieron presentes en todos los
modelos de diseño y esquemas de arquitectura expuestos. Se puede encontrar en las
presentaciones declaraciones de principios como las que se muestran a continuación:
• Leverage Enterprise Design Patterns ([15], sección de conclusiones])
• Use pattern-layered interaction ([15], sección de conclusiones])
• Los patrones de diseño simplifican las interacciones entre clases ([16],
sección de conclusiones])
• Pueden hacer a las aplicaciones de software más escalables y fáciles de
cambiar ([16], sección de conclusiones])

4.3 Patrones de diseño para diseño multilenguaje.

Los patrones de diseño permiten expresar colaboraciones entre clases en forma

unívoca, permitiendo establecer un vocabulario de diseño a un mayor nivel de
abstracción.

Esto permite abstraernos del lenguaje en que se implementa cada clase y

concentrarnos en la colaboración de dicha clase con el resto de su entorno.

5. Ejemplo: Algoritmos en múltiples lenguajes

En esta sección, plantearemos un ejemplo práctico a efectos de demostrar lo
expuesto en las secciones anteriores. Mostraremos como es posible crear en forma
ordenada y planificada una aplicación cuyas funcionalidades estén implementadas
en distintos lenguajes utilizando como guía una serie de patrones de diseño del GoF.

Es importante destacar que lo que se mostrará a continuación son sólo pequeños

ejemplos de la potencia de esta técnica y que han sido planteados a efectos de
mostrar la técnica, con lo cual, su justificación de negocio puede no ser la más
adecuada. De todos modos, preferimos incluir un ejemplo práctico para ilustrar
mejor los conceptos.

5.1 Escenario

Se precisa guardar información sobre contactos en distintos repositorios: una base de

datos Sql Server y ficheros XML. En el caso de la persistencia contra Sql Server,
contamos con una base de código en forma de una librería de clases implementada
en Visual Basic 6.0. Ese código ha sido absolutamente probado y está funcionando
desde hace un tiempo considerable sin problemas. Intentaremos realizar unas
pequeñas modificaciones sobre el mismo para migrar esta funcionalidad a Visual
Basic.NET con esfuerzo mínimo.

La política de desarrollo de nuestra empresa indica utilizar C# siempre que sea

posible, por considerarlo el lenguaje más conveniente para desarrollar con el
framework .NET. Por consiguiente, la persistencia XML, para la cual no tenemos
nada desarrollado, será desarrollada enteramente en C#, utilizando los objetos del
espacio de nombres System.Xml. El proyecto principal (el manejador de la
estrategia) será también desarrollado en C#.

5.2 Patrones a utilizar

Para resolver el problema planteado, utilizaremos principalmente el patrón

Estrategia (Strategy, [1], página 289). Según el GoF, este patrón “Define una familia
de algoritmos, encapsula cada uno de ellos en clases y los hace intercambiables.
Permite que un algoritmo varíe independientemente de los clientes que lo usan”
([1]). De esta manera, podemos implementar cada algoritmo de persistencia en
clases distintos leguajes (persistencia Sql Server en VB.NET y persistencia XML en
C#).

Para guardar los datos en nuestra hipotética agenda basada en base de datos,
necesitamos actualizar múltiples repositorios. La realización de esta actualización es
realizada por varias clases diferentes. Para poder encajar la actualización a nuestra
Estrategia, utilizaremos otro patrón llamado Fachada (Façade). Según el GoF, este
patrón “proporciona una interface unificada para un conjunto de interfaces de un
subsistema. Define una interface de alto nivel que hace que el subsistema sea más
fácil de usar” ([1]). De esta manera, definiremos una fachada para almacenar los
distintos datos en la base de datos.

5.3 Arquitectura de la solución

5.3.1 Lenguaje de Notación

Hemos elegido a UML como lenguaje de notación para especificar nuestro diseño,
debido a su expresividad, versatilidad y a su gran aceptación dentro del mundo de la
ingeniería del software orientado a objetos.

Creemos que es indispensable contar con una herramienta que nos permita
representar el diseño de la aplicación en forma visual, a efectos de establecer una
clara comunicación entre los participantes del equipo de desarrollo.

5.3.2 Diagrama de clases UML

Figura 2 – Diagrama UML de la solución

5.3.3 Extensiones a UML.

Para poder expresar mejor el diseño, hemos empleado los valores etiquetados de
UML para extender el modelo de clases de UML e indicar cómo participa una clase
en un patrón (que rol cumple de acuerdo a las especificaciones del GoF) y en qué
lenguaje será implementada.

Esto nos permite visualizar en forma sencilla cual es el rol de cada clase en el diseño
general de la aplicación y tener una visión panorámica de la distribución de
lenguajes en toda la aplicación, convergiendo en mayor control sobre el diseño e
implantación del proyecto.
Extensión Significado
{Patron=valor} Patrón identificado de la especificación de GoF.
{Rol=valor} Cuál es el rol que cumple la clase dentro del patrón, de
acuerdo con las especificaciones del GoF.
El valor puede ser un vector de elementos, como en el
caso de la clase cSQLPerson que tiene los roles de
Façade en el patrón Façade y Estrategia Concreta en el
patrón Estrategy
{Lenguaje=valor} Indica en que lenguaje se implementa la clase, en este
caso C# y VB .NET

5.3.4 Solución de Visual Studio.NET.

La aplicación será implementada en Visual Studio .NET (VS.NET) mediante un

conjunto de proyectos, donde cada uno (con sus clases y elementos constituyentes)
cumple un rol específico acorde a lo especificado en el diagrama anterior. En la
figura 3 que se muestra a continuación, es posible visualizar la implementación
física de la solución en Visual Studio .NET.

Figura 3 – Estructura de proyectos de la solución

5.4 Migrando el código VB 6.0 a VB.NET

La migración del código existente de Visual Basic 6.0 a VB.NET es muy sencilla.
Las únicas diferencias tienen que ver con los objetos de acceso a datos: la primera
utiliza ADO mientras que la última ADO.NET. De todos modos, la adaptación es
muy sencilla: solo se modifican algunos detalles de implementación referentes al
uso de los objetos de ADO.

Código VB 6 Código VB.NET

Sub GuardarPersona(params) Sub GuardarPersona(params)
Dim sSql As String Dim sSql As String
Dim oConn As Connection Dim oConn As SqlConnection
Dim oCmd As SqlCommand

'creacion del objeto conexion 'creacion del objeto conexion

Set oConn = New Connection oConn = new SqlConnection()
'apertura de la conexión 'apertura de la conexion
oConn.Open gConnStr oConn.Open gConnStr
'armado de la sentencia SQL 'armado de la sentencia SQL
sSql = “mi sentencia SQL” sSql = “mi sentencia SQL”
'ejecucion de la sentencia sql 'ejecución de la sentencia sql
oConn.Execute sSql oCmd = oConn.CreateCommand()
oCmd.CommandText = sSql.
oCmd.ExecuteNonQuery()
'liberaciçon de la conexión 'liberaciçon de la conexión
oConn.Close oConn.Close()
Set oConn = nothing oCmd.Dispose()
oConn.Dispose()
End Sub End Sub
Listado 1 – Comparación de bloques de código entre VB6 y VB.NET. Nótense las
similitudes entre ambos bloques de código. El texto en itálico corresponde a tareas
que no se realizaban en VB6.

Nota importante: este código ha sido creado a efectos de ilustrar la situación, pero
no cumple las normas de calidad de código de producción real. Una mejora
importante seria incluir en ambos casos control de error o un manejo más inteligente
del estado de la conexión.

5.5 Implementando la estrategia

Como hemos mencionado anteriormente, utilizaremos el patrón Strategy (Estrategia)

para encapsular cada algoritmo de guardado en distintas clases, las cuales estarán
implementadas en distintos lenguajes.

A continuación, enumeraremos los elementos que conforman al patrón estrategia

con su respectivo artefacto dentro de la solución:
• Estrategia (IStrategy):
- declara una interface común a todos los algoritmos permitidos. El
Contexto (cContext) usa esta interface para llamar al algoritmo
definido por una EstrategiaConcreta (cSqlPerson, cXmlPerson).
• EstrategiaConcreta (cSqlPerson, cXmlPerson):
 - implementa el algoritmo utilizando la interface de la Estrategia
(IStrategy)
- en este caso, las estrategias concretas son cSqlPerson para
persistencia de datos en Sql Server (implementada en VB.NET) y
cXmlPerson para persistencia en Xml (implentada en C#).
• Contexto (cContext):
- se configura con una EstrategiaConcreta (cSqlPerson,
cXmlPerson)
- mantiene una referencia a un objeto Estrategia (IStrategy)
- puede definir una interface que permita a la Estrategia acceder a
sus datos

5.6 La fachada para almacenamiento de datos en Sql Server

En el caso de la persistencia de datos en Sql Server (cSqlPerson), tenemos varios

objetos, donde cada uno se encarga de la persistencia de distintas piezas de
información en diferentes tablas. Con esta estructura, podemos tener una cantidad
indefinida de teléfonos y direcciones de correo para cada persona como se muestra
en la figura a continuación.

Figura 4 – Diagrama entidad relación del almacenamiento de datos en SQL Server.

A estos efectos, contamos con las siguientes clases:

• cPersonData: almacenar datos en la tabla Personas.
• cPersonMail: almacenar datos en la tabla MailXPersona.
• cPersonPhone: almacenar datos en la tabla TelefonosXPersona.

Para poder proveer una clase única donde implementar la estrategia, utilizaremos el
patrón façade (Fachada), el cual tiene los siguientes participantes:
• Fachada (cSqlPerson)
- sabe qué clases del subsistema son las responsables ante una
petición.
- delega las peticiones de los clientes en los objetos apropiados del
subsistema.
• Clases del subsistema (cPersonData, cPersonMail, cPersonPhone)
- implementan la funcionalidad del subsistema.
- realizan las labores encomendadas por el objeto Fachada.
- no conocen a la fachada: es decir, no tienen navegabilidad hacia
ella.
5.7 Combinando los patrones para la persistencia de datos a Sql Server

La clase cSqlPerson es una fachada de cPersonData, cPersonMail y cPersonPhone.

Esta clase es la que implementa la interface de la estrategia IStrategy, convirtiéndose
también de esta manera en la EstrategiaConcreta necesaria para el patrón
Estrategia.

5.8 La persistencia XML

La persistencia de datos en repositorios XML será desarrollada con C#, sin tener una
base previa. Para implementar esta funcionalidad, utilizaremos los objetos del
espacio de nombres (namespace) System.Xml.

5.9 La aplicación cliente

La aplicación cliente es muy sencilla: consta de un formulario Windows Form en el

cual se ingresan los datos y luego invoca oportunamente al método de persistencia
adecuada, según sea solicitado por el usuario.

A continuación, mostraremos la forma de invocar a cada método de persistencia,

para demostrar la aplicación práctica de la técnica en su conjunto. Nótese la sutil
diferencia en la invocación de los métodos de persistencia (marcada en negrita): en
la invocación de los métodos de persistencia hay una abstracción absoluta de los
métodos utilizados para la persistencia real de los datos.

Persistencia a Xml Persistencia a Sql Server

// creacion los objetos de persistencia // creacion los objetos de persistencia
cContext c = new cContext(new cContext c = new cContext(new
cXmlPerson()); cSqlPerson());

cPerson thePerson = new cPerson(); cPerson thePerson = new cPerson();

// asignacion de los datos de la persona // asignacion de los datos de la persona

thePerson.Id = 1;
thePerson.Nombre = "Juan";
thePerson.Apellido1 = "Perez";
thePerson.Apellido2 = "Gomez";
thePerson.Mail = "juanperez@mail.com";
thePerson.Telefono = "123456789";
thePerson.Id = 1;
thePerson.Nombre = "Juan";
thePerson.Apellido1 = "Perez";
thePerson.Apellido2 = "Gomez";
thePerson.Mail = "juanperez@mail.com";
thePerson.Telefono = "123456789";

// guardado los datos // guardado los datos

c.Save(thePerson); c.Save(thePerson);
Listado 2 – Clientes de la estrategia

6. Generalización
El esquema presentado en las secciones anteriores tiene amplia aplicación en varias
áreas de la ingeniería del software orientado a objetos: aplicaciones distribuidas,
aplicaciones orientadas a objetos y aplicaciones en n-capas, por citar algunas.
El uso de patrones para combinar múltiples lenguajes no está sólo restringido a los
lenguajes por defecto de Visual Studio .NET (C#, VB.NET y C++.NET): es una
técnica que se puede hacer extensiva a cualquier lenguaje que pueda utilizarse
dentro de la plataforma .NET. Así, podemos integrar nuestro código con bloques
escritos en COBOL (utilizando el compilador de COBOL .NET desarrolado por
Fujitsu [3]), Eiffel (utilizando Eiffel# o el compilador de Eiffel desarrollado para
.NET), Fortran, Pyton, Perl o cualquier lenguaje que tenga un compilador que
genere código que el CLR pueda ejecutar (actualmente, hay mas XXX lenguajes
compatibles).

De esta manera, podemos aprovechar en los casos necesarios las características

excepcionales de cada lenguaje: a modo de ejemplo, podemos citar el caso de Eiffel
que implementa la herencia múltiple real (a diferencia de la implementación por
defecto de .NET, que permite heredar de una clase y luego de múltiples interfaces
[7]) o la sintaxis especializada en manejo de ficheros de datos de COBOL.

También podemos utilizar esta técnica para ir migrando aplicaciones en forma

progresiva. El ejemplo planteado en el punto anterior puede ser un caso de este
escenario, aunque sea extremadamente sencillo. Otro ejemplo interesante en este
escenario es encapsular viejas funciones COBOL en clases COBOL.NET y
heredarlas o utilizarlas en programas nuevos, desarrollados con C# o cualquiera de
los lenguajes de VS.NET. De esta manera, podemos reutilizar algoritmos o rutinas
que no están bien documentadas y el costo de volver a escribirlas hacen prohibitiva
su migración o integración con otras aplicaciones. Progresivamente, estas rutinas
pueden ir siendo migradas a nuestro lenguaje de preferencia, modificando sólo las
clases donde se implementan dichas rutinas y sin afectar a la aplicación en su
conjunto.

A estos efectos, recomendamos realizar pruebas de unidad. Un buen producto para

esto es el NUnit [18], desarrollado por Kent Beck y James Newkirk, que brinda un
marco para crear y ejecutar pruebas de unidad .

7. Conclusiones
El diseño debe ser el centro de desarrollo del proyecto. En el reside toda la
información necesaria para mantener, ampliar o reutilizar las funcionalidades de una
aplicación. El uso de reglas, técnicas y experiencias anteriores de diseño nos
permitirá obtener mejores resultados.

La utilización de patrones de diseño para obtener un diseño claro y efectivo de la

aplicación disminuye la dificultad de implementación de este tipo de soluciones,
donde el diseño es un concepto fundamental para obtener buenos resultados.

Por lo tanto, los Patrones de Diseño son de gran ayuda para implementar
aplicaciones multilenguaje en forma eficiente y ordenada, contrarrestando los altos
niveles de entropía inherentes a ese tipo de aplicaciones.

Referencias
1. Gamma, Erich, Helm, Richard, Johnson, Ralph & John Vlissides: Design
Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley,
1995
2. Platt, David: Introducción Microsoft .NET, Microsoft Press, 2001
3. Appleman, Dan: Moving to VB.NET, APress, 2001
4. Appleman, Dan: ActiveX Component Development Guide, Apress, 1997
5. Gunnerson, Eric: C# programmers guide, 2001
6. Meyer, Bertrand: Polyglot Programming [en línea] <
http://www.sdmagazine.com >
7. Meyer, Bertrand: Achieving Interoperability [en línea] <
http://www.sdmagazine.com >
8. Cole, Thomas: Jump from ADO to ADO.NET [en línea] <
http://www.vbwm.com/articles/2002/tcole/adonet1/printable_article.asp >
9. Jacobson, Ivar: Object-Oriented Software Engineering: a use case driven
approach, ACM Press, 1991
10. Appleman, Dan: ActiveX Component Development Guide, APress, 1998
11. Fujitsu: COBOL for Microsoft .NET Framework [en línea] <
http://www.adtools.com/info/whitepaper/net.html >
12. Mono Project [en línea]
13. Microsoft Architecture Center [en línea] <
http://msdn.microsoft.com/architecture >
14. Microsoft Patterns and Practices [en línea ] <
http://msdn.microsoft.com/patterns >
15. Sehmi, Arvindra & Carraro, Gianpaolo: Architecting for Interoperability
Framework, Proceedings from the Microsoft EMEA Tour 2003, Madrid
16. Sehmi, Arvindra: Pattern Layering: secret sauce of great applications,
Proceedings from the Microsoft EMEA Tour 2003, Madrid
17. OMG <en línea> http://www.omg.org
18. NUnit <en línea> http://www.nunit.org