Uso de Propiedades en lugar de Variables Globales

Hola ¿Qué tal?…


Ahora que hemos estado hablando de variables globales y de no utilizarlas porque ya no son más necesarias dada las nuevas características de Visual Basic.NET, inclusive de C#, primeramente tendré que explicar cómo funcionan las variables globales en Visual Basic .NET y además, dejar una alternativa eficiente para sustituir su uso, dejando a ustedes la libertad de usar la que más les convenga.


Bueno, quisiera explicar cómo se utilizan las variables globales en Visual Basic.NET y qué es lo que pasa atrás de todo eso al compilarse una aplicación de Visual Basic.NET.


Para declarar una variable global en Visual Basic.NET se agrega un module al proyecto, como en Visual Basic 6. En este module se escriben las variables y los métodos como se hacía en VB6, no es raro que sea posible dada la compatibilidad de escritura de código con las versiones anteriores al .NET Framework, sin embargo no es tal cual era en VB6, el detalle es que el compilador de VB.NET convertirá ese module en una clase con miembros estáticos, lo que no es tan malo si pensamos que el contenido está compuesto de puros métodos, ya que los métodos estáticos (shared en Visual Basic) son útiles para tareas frecuentes donde no vale la pena utilizar una instancia para usarlos, el problema está en el uso de las variables públicas, que en este caso serán compilados como campos estáticos (shared en Visual Basic) de la clase. Estos campos estáticos estaran disponibles con sus valores para ser utilizados en la aplicación, en cualquier momento. Estos campos estarán ocupando un espacio en memoria en todo momento con el contenido que se les haya definido o asignado, no es tan malo a primera vista, sin embargo, el rendimiento de una aplicación se verá afectado en proporción a la cantidad de campos estáticos que estén presentes en estos modules. Además, los campos estáticos delimitan la portabilidad de la aplicación, pensando en portar la funcionalidad de una aplicación Windows a Web, ya que en web el estado de estas variables no se mantiene entre llamadas (post back) al servidor como podría esperarse. Así que si la funcionalidad se basa en el uso de campos estáticos (como si de variables globales se tratara) entonces implicaría un rediseño de la funcionalidad para web. Pero… ¿Qué pasa con los métodos estáticos?, ¿por qué no son tan malos?, bueno, la funcionalidad de un método estático está basada en la ejecución de un bloque de código en el instante en que se requiere sin esperar que guarde algún estado, esto es, que se utiliza como funcionalidad volátil, solo para lo que es y listo, dejando que el Garbage Collector se encargue de las variables que han perdido ámbito dentro del método, estos métodos son también útiles en Web, ya que se utilizan mientras se ejecuta la llamada en el servidor. Es obvio que no toda la funcionalidad puede dejarse expuesta en métodos estáticos según la naturaleza de cada aplicación o componente, ya que habrá situaciones en las que sea requerida una instancia para utilizar un método debido a los distintos escenarios de inicialización de una clase.


Ok, pensemos en Windows Forms, que es donde más se utilizan las variables globales y donde más se extrañan. Si queremos disponer de cierto valor generado en un formulario y pasarlo a otro, se pueden utilizar las propiedades, sin embargo, el uso de toda esta metodología obliga a la definición de la aplicación basado en el flujo de información, esto es, no disponemos ya de los formularios como lo hacíamos en VB6, el formulario que se quiere utilizar, ahora se debe hacer por medio de instancias. Bien, pensemos en un formulario principal, si he de pasar un valor definido en el formulario principal a un formulario secundario, puedo hacerlo pasando el valor a través de una propiedad definida en el formulario secundario, es muy simple, solo debemos definir la propiedad en el formulario secundario y  utilizarla con la variable de instancia declarada en el formulario principal, el cual lanzará al formulario secundario, como se muestra en el siguiente código:


En el formulario principal (Form1):

    Private Sub Button1_Click(ByVal sender As System.Object, _
           ByVal e As System.EventArgs) Handles Button1.Click
        Dim frm As Form2 = New Form2()
        frm.Identificador = 2
        frm.Show()

    End Sub


En el formulario secundario (Form2):

    Private mIdentificador As Integer
    Public Property Identificador() As Integer
        Get
            Return mIdentificador
        End Get
        Set(ByVal value As Integer)
            mIdentificador = value
        End Set

    End Property


En el formulario secundario (Form2), se tiene declarada una propiedad denominada Identificador, las propiedades comúnmente se apoyan de un campo privado en el cual almacenan el valor de entrada obtenido por el bloque Get de la propiedad. Este campo privado, se puede utilizar en cualquier parte de la clase sin problemas, por lo que la información estará disponible en todo momento en toda la clase Form2, así, no tendremos necesidad de una variable global, ya que la información ya la tengo al alcance pero de manera local, esto es, en la clase que la necesitaba y no estará disponible para todas las clases de la aplicación a pesar de la requieran o no.


Las propiedades dependen de una variable para almacenar el valor de entrada y para exponer el valor de salida y para trabajar con estos valores en otras partes de la clase, sin embargo, hablando de formularios, ese valor puede ser almacenado en la propiedad de algún otro objeto, por ejemplo, en la propiedad Text de una caja de texto o de una etiqueta, veamos el equivalente a la propiedad anterior utilizando un TextBox llamado TextBox1:

    Public Property Identificador() As Integer
        Get
            Dim int As Integer
            Try
                int = Integer.Parse(TextBox1.Text)
            Catch ex As Exception
                int = -1
            End Try
            Return int
        End Get
        Set(ByVal value As Integer)
            TextBox1.Text = value.ToString()
        End Set

    End Property


Bien, esto podría ser otra opción para utilizar las propiedades, vemos aquí que se utiliza el TextBox1 directamente para manejar los valores, así pues, al utilizar la propiedad desde el Formulario principal, entonces la mostrar el formulario se mostrará con el valor asignado en el TextBox1.


El uso de las propiedades no es tan difícil, ni implica dificultad alguna, seguro podrán ver las ventajas de utilizar propiedades propias en sus formularios, pues tendrán un medio de comunicación con sus formularios. El canal de comunicación se cierra con las respuestas, y esto se logra a través de eventos, por lo que pueden consultar dentro de este blog el post acerca de delegados y eventos para ver ese forma de comunicación.


Ahora, a diferencia de VB6, podemos ver a los formularios como clases, y como tales, podemos extenderlas a nuestras necesidades, bueno… esto también era posible en VB6, así que, les recomiendo que si ven una buena oportunidad para utilizarlas, no lo duden, seguro que encontrarán grandes ventajas en ello.


Con lo que respecta a las variables globales, quiero dejar aquí una opción para sustituirlas de forma eficiente, en un futuro, mostraré otra manera de evitar el uso de variables globales, o bien, sustituirlas por un método eficiente alternativo.


Saludos…


Octavio Telis

5 thoughts on “Uso de Propiedades en lugar de Variables Globales”

  1. felicitaciones, sin embargo el uso de propiedades abarca más campos que solamente usarlos en formularios, pues es más funcional cuando se utilizan clases…

  2. yo tengo una dificultad con mi jefe ya que el desaprueba el uso de propiedades argumentado que requieren un procesamiento mayor y más código pidiendo declarar esas variables como Public.

    yo prefiero usar las propiedades ya que me permiten validar el valor antes de asignarlo y porque los valores de resultado permanecen ReadOnly dandole (creo yo) más estabilidad y seguridad.

    que opinas al respecto?

  3. este problema me tope, y entiendo lo que expones, ahora mi pregunta es, se puede poner esta propiedad en una clase que tengo para todo mi aplicacion y desde el formulario principal instanciar la propiedad de la clase y darle un valor y en mi formulario secundario, instanciar la propiedad y recoger el valor ?, es lo mismo que expones, es correcta esa manera, o seria mejor como lo expones?

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>