Estructuras o clases, ¿cuál debemos utilizar?

Llegados a este punto, el lector puede estar preguntándose cuál sería la mejor manera de abordar la aplicación: con clases o estructuras. Bien, no podemos decantarnos totalmente por un modo u otro de trabajo. Aún guardando muchas similitudes con las clases, las estructuras mantienen ciertas diferencias respecto a las primeras, que harán conveniente su uso en determinados momentos, siendo menos adecuadas en otras situaciones.

Las estructuras no soportan herencia, por lo que el medio más parecido que tenemos de extender sus funcionalidades es a través de interfaces.

Para crear un manejador de evento dentro de una estructura, el procedimiento que actúe como manejador deberá ser un miembro compartido, no podrá ser un miembro de instancia. El manejo de eventos será tratado posteriormente.

Una estructura es un tipo por valor, lo que quiere decir que los datos que contiene se manejan en la pila (stack) de la memoria. Si asignamos una variable que contiene una estructura a otra variable, se realizará una copia de la estructura, y obtendremos dos estructuras cuyos datos serán totalmente independientes.

Esto último contrasta claramente con las clases, que son tipos por referencia, y sus datos se manejan en el montón (heap) de la memoria. Lo que realmente contiene una variable de objeto no es el objeto en sí, sino un puntero de cuatro bytes, con la referencia hacia la zona de memoria en la que reside el objeto. Por lo tanto, si asignamos una variable de objeto a otra variable, se realiza lo que se denomina

una copia superficial (shallow copy) de una variable a otra. Esto quiere decir que sólo se copia el puntero de cuatro bytes que contiene la referencia hacia el objeto. El efecto conseguido son dos variables que apuntan al mismo objeto y no dos variables con copias independientes del objeto.

Observemos el Código fuente 286, en el que se crean dos variables de estructura y una se asigna a otra. Si hacemos un cambio en la segunda, la primera estructura permanecerá inalterada. Sin embargo,

a continuación creamos dos variables de objeto, y asignamos la primera a la segunda. Cuando hagamos un cambio en la segunda, se reflejará en la primera; esto es debido a que son dos variables que apuntan al mismo objeto.

Sub Main() Dim lDBanco1 As DatosBanco Dim lDBanco2 As DatosBanco

lDBanco1.IDCuenta = 55 lDBanco2 = lDBanco1 lDBanco2.IDCuenta = 188

Console.WriteLine("lDBanco1.IDCuenta --> {0}", lDBanco1.IDCuenta) ' 55 Console.WriteLine("lDBanco2.IDCuenta --> {0}", lDBanco2.IDCuenta) ' 188

Console.WriteLine()

Dim loEmpleado1 As Empleado Dim loEmpleado2 As Empleado

loEmpleado1 = New Empleado() loEmpleado1.piIdentificador = 55 loEmpleado2 = loEmpleado1 loEmpleado2.piIdentificador = 188

Console.WriteLine("loEmpleado1.piIdentificador --> {0}", _ loEmpleado1.piIdentificador) ' 188 Console.WriteLine("loEmpleado2.piIdentificador --> {0}", _ loEmpleado2.piIdentificador) ' 188

Console.ReadLine() End Sub

Código fuente 286

Siguiendo con este mismo aspecto del manejo en memoria de las estructuras , queremos hacer notar al lector que al tratarse de tipos por valor, podemos realizar sobre ellas operaciones de embalaje y desembalaje de tipos (boxing - unboxing). Consulte el lector en el tema dedicado a .NET Framework, el apartado dedicado a este tipo de operaciones.

Si embalamos una estructura, asignándola a una variable tipificada como Object, o pasándola a un procedimiento que tiene el parámetro declarado como Object, y posteriormente la desembalamos, volviéndola a asignar a una variable del tipo de la estructura, incurriremos en una penalización sobre el rendimiento, debido a que el CLR debe manipular la variable en el montón cuando es tratada como un objeto y después devolverla a la pila cuando se vuelve a tratar como una estructura. Por consiguiente, si vamos a tratar la estructura mayormente como un objeto, debemos considerar la posibilidad de crear mejor una clase.

Estructuras o clases, ¿cuál debemos utilizar?