Desde hace ya bastante tiempo utilizo VB.NET para programar y una de las cosas que me parecieron curiosas cuando pasé de VB6 a VB.NET fue la posibilidad de definir variables como ReadOnly ¿que finalidad podría tener una variable de tipo solo lectura si precisamente cuando definimos una variable lo que queremos es que su valor cambie?, si una variable no puede modificarse ¿no sería lo mismo que una constante?
Pues hace unos días me encontré con un escenario que tiene justo ese matiz que hace posible esta distinción entre una variable ReadOnly y una constante.
Mi caso particular fue una solución de VB.NET que contenía dos proyectos. Uno de ellos era una Aplicación de Windows Forms y el otro era del tipo Biblioteca de clases, es decir, un archivo EXE y una DLL. La idea de este proyecto era tener una serie de funciones en la DLL que serian llamados desde el EXE, algo que es muy frecuente en programación. El caso es que, en un momento dado, el EXE muestra un mensaje definido dentro de la DLL y es aquí donde encontré la particularidad.
El mensaje estaba definido en la DLL como una constante dentro de una clase, es decir, algo así:
Public Class MiClase
Public Const Mensaje As String = "Bienvenidos a California"
End Class
y se llamaba desde el EXE utilizando algo así:
Public Class MiForm
Private Sub MiForm_Load(ByVal sender As System.Object,ByVal e As System.EventArgs) Handles MyBase.Load
MessageBox.Show(MiDLL.MiClase.Mensaje)
End Sub
End Class
Se compiló el proyecto y todo funcionaba correctamente, el EXE mostraba el mensaje sin problemas pero poco después se decidió cambiar el mensaje "Bienvenidos a California" por el texto "Bienvenidos a Florida" así que, en principio, solo era necesario modificar el valor definido en la constante y volver a compilar la DLL pero no fue así.
Pese a haber realizado la modificación correctamente el EXE seguía mostrando el mensaje "Bienvenidos a California" y esto es debido a que el compilador "incrusta" el valor de las constantes dentro del EXE por lo que por mucho que se cambie su valor en la DLL, si no se vuelve a compilar el EXE no tendrá ningún efecto.
Para evitar este tipo de situaciones se puede que definir como ReadOnly de forma que el compilador siempre obtenga su valor de la DLL quedando así:
Public Class MiClase
Public Shared ReadOnly Mensaje As String = "Bienvenidos a California"
End Class
Una vez compilado el proyecto (tanto el EXE como la DLL) si se podrán hacer los cambios posteriores sobre la DLL sin necesidad de volver a compilar el EXE.
Después de esto la pregunta es ¿cuando se pueden utilizar constantes? pues, visto lo visto, creo que lo mejor es definir constantes cuando su valor no puede cambiar nunca y cuando digo que no puede cambiar nunca no me refiero a que no vaya a cambiar sino a que realmente no puede cambiar. En nuestro caso anterior el mensaje puede cambiar, de hecho, se quiso que cambiara y se cambió pero una constante de verdad no puede cambiar, por ejemplo, la velocidad de la luz es una constante y no puede cambiar... y, en fin, si alguien la cambia y cambia todos los principios de la física tampoco nos vamos a poner nosotros tiquismiquis para no querer cambiar nuestra aplicación ¿no?.
Siempre viene bien conocer estos "comportamientos esperados".
ResponderEliminarMuy cierto indigenica, este tipo de cosas entra en lo que Microsoft llama "comportamiento esperado de la aplicación" :D por eso hay que tener muy claro como "piensa" el lenguaje de programación que utilizamos y no siempre es fácil de entender.
Eliminar