 En la actualidad hablamos cada vez más de VFP y .NET. Este escrito y los ejemplos que se publicarán a continuación pretenden mostrar mis experiencias al trabajar con ambas herramientas. Queda mucho por decir. Así que… mantengámonos en contacto, y aprendamos… que hay futuro para este tema.
Interoperabilidad VFP y .NETPor Amby
Me motivan a escribir sobre este tema los continuos debates en foros de VFP, sobre temas que unen o dividen a Visual FoxPro y .NET. Para comenzar cualquier análisis sobre el tema, repasaría el enfoque dado por Claudio Lassala, foxero y desarrollador experimentado en C#.NET, actualmente Claudio es MVP en C#.NET. El artículo se titula "Visual FoxPro y .NET: lo mejor de ambos mundos" y se puede leer en idioma español en:http://www.portalfox.com/article.php?sid=1161 En este artículo, Claudio Lassala detalla varias razones por las que se debe enfocar desde un punto de vista constructivo, aprovechando, como el dice, "lo mejor de ambos mundos". Sobre esta base, que en lo personal, yo comparto, les propongo ver algunas características de la Programación Orientada a Objetos desde .NET y desde VFP. Mis comentarios están basados en un grupo de artículos escritos por el propio Claudio Lassala junto a Markus Egger. Además me he basado en escritos de Cathy Gero, Les Pinter y Rick Strahl. Al final de este escrito se muestran enlaces a sitios y artículos de interés. Vamos al tema. OOP en VFP y .NETAunque consideramos que VFP es un lenguaje construido sobre bases OOP, en realidad VFP admite programación procedural y OOP Veamos este ejemplo: | VFP | VB.NET |
|---|
LOCAL loObject
loObject = CREATEOBJECT("TestClass")
? loObject.GetCurrentDate()
DEFINE CLASS TestClass AS CUSTOM
FUNCTION GetCurrentDate()
RETURN "La fecha es: " + TRANSFORM(DATE())
ENDFUNC
ENDEFINE | Console.Writeline("La fecha es: "+ Datetime.Today.ToString)) |
En este caso utilizamos un método de un objeto, que se basa en una clase heredada de una clase base VFP - Custom. A primera vista es un código OOP. Pero estamos utilizando dos funciones Date() y Transform() para devolver la fecha y convertirla en cadena. Estas funciones NO son miembros de objetos, por tanto, es procedural. En Visual Studio .NET, no hay función Date() ni tampoco Transform() En su lugar hay un objeto DateTime que tiene una cantidad de PM que devuelven la fecha, la hora, etc. El código VB.NET emplea la función Today para devolver la fecha y Console.WriteLine para mostrar la salida, es el equivalente con "?" de VFP. En C# la diferencia es un punto y coma al final. Sobre Transform(), vemos como primera diferencia que l dato devuelto por Date() no es un objeto, no tiene PEMs. En .NET, todo es un objeto, por tanto, el valor almacenado en la propiedad Today es un objeto de la clase DateTime. Este objeto, a su vez, tiene PEMs, uno de ellos es el equivalente a Transform() es el método ToString() Definición de clases| VFP | VB.NET | C#.NET |
|---|
DEFINE CLASS TestClass AS Custom
ENDDEFINE | Public Class TestClass
End Class | public class TestClass
{
} | | | Public Class TestClass
Inherits Object
End Class | public class TestClass : Object
{
} |
Aquí vemos cómo la apariencia es un poco diferente; pero la idea es la misma. - VFP y VB.NET emplean una palabra END para indicar término de la definición. C#, por su parte emplea llaves (})
- Como en .NET todo es objeto, si el compilador encuentra clases que no definen una clase padre, se selecciona automáticamente la clase Object. Se puede indicar de esta forma Inherits Object
Por estos elementos comunes entre las dos herramientas, vemos que los desarrolladores VFP tienen un camino andado cuando van a aprender .NET. Hay más… Escritura estrictamente tipada | VFP | VB.NET |
|---|
LOCAL oForm
oForm = CreateObject("Form")
oForm = CreateObject("TestClass")
oForm.Show() | Dim oForm as Form
oForm = New Form |
En VFP se pueden cometer estos errores, recordemos que la clase TestClass, que fue definida anteriormente, no tiene método Show. Entonces, mientras VFP admite este código en tiempo de diseño y programación, va a fallar en tiempo de ejecución, por su parte, en VS.NET, todo es un objeto; pero no es cualquier objeto. Siempre que los objetos son utilizados, son de una clase determinada. La palabra clave "Dim" es similar a Local de VFP En ambos casos existe la cláusula AS; pero no nos debemos confundir. En VFP el compilador ignora esta referencia, se incluyó en VFP 7.0 solo a efectos de IntelliSense. | VFP | VB.NET |
|---|
LOCAL oForm as Object
LOCAL oForm as Form
LOCAL oForm As Object
oForm = "Hola mundo!"
? oForm | Dim oForm As Form
Dim sTest as String
sTest = "Hola mundo!"
oForm = sTest |
En .NET si referencia la variable con su tipo. Este código genera error en .NET. El compilador de VB.NET compara el tipo de variable con el valor asignado, se da cuenta de que es una cadena y no un formulario y no compila. Una diferencia interesante y es un punto a favor de .NET es que se pueden hacer dos pasos en uno: Dim oForm As Form = new Form
Dim oForm As New Form Se agradecería que VFP aceptara una sintaxis del tipo: LOCAL oForm = CreateObject("Form") Espacios de nombreLo más parecido a los espacios de nombre en VFP son las bibliotecas de clases. Una de las mayores diferencias es que el namespace de una clase forma parte de su nombre Public Namespace MyNamespace
Public Class TestClass
End Class
End Namespace Ahora puede instanciar una clase llamada "TestClass." Pero este es sólo el nombre informal de la clase. Su nombre real es "MyNamespace.TestClass." Cuando utilizar el nombre completo o no depende de la situación. En nuestros ejemplos veremos que para no utilizar los nombres tan largos, se definen al inicio del todo del código. En C#: using MyNamespace; En VB: Imports MyNamespace Después de esta declaración, se puede utilizar el nombre corto, aunque es válido emplear el nombre largo. Podemos verlo como nuestro: SET PROCEDURE TO
*-- ó --
SET CLASSLIB TO Podemos imaginar que son bibliotecas de clases; pero no es lo mismo. Es mucho más fácil mantener muchos namespaces que muchas bibliotecas de clases. Los namespaces no tienen nada que ver con localización física de archivos. Pueden ser ordenadas jerárquicamente. Por ejemplo, todas las clases relacionadas con Windows se guardan en System.Windows, todas las relativas a Web, System.Web. HerenciaA la vista no saltan grandes diferencias, el sentido es el mismo; pero SI hay diferencias. Como vimos antes en .NET la clase Contacto no indica su clase padre, mientras que en VFP está claramente definido que hereda de Custom En .NET - Inherits y en VFP AS En .NET la herencia se indica en una línea nueva, en VFP en la misma instrucción Heredar y sobreescribir métodosSi programamos en .NET pensando en VFP y queremos sobreescribir el comportamiento de un método, escribimos el código en la instancia actual y asumimos que el compilador entenderá que debe ignorar lo que existía en la clase padre o alguna en la herencia. .NET no lo entiende así, entiende que ha habido un accidente, va a ignorar lo instanciado actualmente y ejecutará lo que hay en la herencia, a no ser que se le indique directamente al compilador que explícitamente estamos intentando sobrescribir este comportamiento. En C# cláusula override y en VB - overrides Public Class Customer
Inherits Contact Public Overrides Function GetFullName() As String
Return "Lassala, Claudio"
End Function
... Pero aun así no es suficiente. El compilador aun no está satisfecho. El problema está en que al definir el método no se indicó que sería sobreescribible. Esto es nuevo para desarrolladores VFP. El comportamiento predeterminado es NO sobreescribible, se debe a que tiene mayor control y se logra mejor rendimiento. En C# - palabra clave virtual En VB.NET, palabra clave Overridable. Public Class Contact
Public Overridable Function GetFullName() As String
Return "Egger, Markus"
End Function
... Se pueden sobreescribir clases, este comportamiento si es predeterminado, para el comportamiento contrario se indica sealed (C#) and NotInheritable (VB.NET). Comparar métodos, propiedades y camposAdemás de las diferencias evidentes en cuanto al lenguaje VFP, VB.Net y C# los métodos no son muy diferentes, son acciones que un objeto puede acometer. La llamada de un método en los 3 lenguajes se realiza de igual forma. En .Net s imprescindible definir el tipo de los parámetros y el tipo retornado por el método. Hay que especificar si los parámetros se pasan por valor o por referencia. Aquí hay ayuda del IDE de .Net que escribe de forma predeterminada by Value. En C#, se eliminan las palabras procedure / function y se escribe primero el tipo de parámetro y luego el nombre. Sobre el valor de retorno VFP todos los métodos retornan algo, aun cuando se escribe return o no se escribe, se retorna .T. En C# hay que declarar el Return como void y tendremos entonces un método que no devuelve nada. En VB.Net existen Sub (subrutinas) que tiene igual comportamiento. Visibilidad del métodoEste es un aspecto en el que nos vemos perjudicados, porque nos podemos confundir, los conceptos son diferentes. VFP el predeterminado es Public, puede ser Protected y Hidden VB.Net es igual C# el predeterminado es Private (visible solo por la clase, invisible para el resto, incluidos sus hijos.) Recomendación: Indicar siempre la visibilidad porque el predeterminado puede traer un comportamiento completamente diferente en C# y VFP Nombres de métodos repetidosEn VFP no se admiten nombres de métodos repetidos para un mismo objeto. En .Net se pueden repetir los métodos, porque cambia la cantidad y tipo de parámetros, esto se conoce como method overlading. Ventaja: No es necesaria ni una línea de código para la verificación del dato. ¿Y cómo podemos ver estos aspectos en la práctica? En los próximos días se irán publicando varios ejemplos de cómo pueden interactuar la herramientas. - Consumir en NET datos VFP con OLE DB
- Consumir componentes COM VFP desde .NET
- Exponer desde .NET objetos VFP como Servicios Web
- Consumir Servicios Web .NET desde VFP
Conclusiones Visual FoxPro es una herramienta de programación de aplicaciones que se encuentra en constante perfeccionamiento. .NET es una herramienta estable y actual que brinda un conjunto de clases y capacidad integrada de gran utilidad para los desarrolladores. La mejor perspectiva es sin dudas: "Aprovechar lo mejor de ambos mundos". Los desarrolladores VFP tienen un gran adelanto a la hora de asimilar y aprender las técnicas de .NET, por la base común de Programación Orientada a Objeto. Esto es apenas una introducción a partir de mis propias experiencias, queda mucho por decir, estudiar y aprender. Ver además: Cuando ya pensaba enviar estas líneas a PortalFox, encontré estos enlaces en la página principal de MS VFP (http://msdn.microsoft.com/vfoxpro). Quedan citar también dos libros: Saludos, Ana María Bisbé York
www.amby.net
|
