Buscador

Elementos compartidos e interfaces - III

En el caso de clases heredadas, y con métodos sobrescritos, CType( ) discierne la implementación de clase a la que debe dirigirse. 
Si añadimos la clase Administrativo como hija de Empleado, y sobrescribimos el método VerDatos( ), cuando pasemos al procedimiento ManipularVarios( ) un objeto Administrativo, dado que esta clase hereda de Empleado, con un sencillo cambio en la estructura Select...Case que comprueba el tipo de objeto, ejecutaremos la implementación sobrescrita del método VerDatos( ) en la clase Administrativo. Veamos el Código fuente 283.

Module Module1
Public Sub Main()
Dim loEmple As New Empleado()
loEmple.piID = 58
loEmple.psNombre = "Elena Peral"
ManipularVarios(loEmple)
Dim loAdmin As New Administrativo()
loAdmin.piID = 80
loAdmin.psNombre = "Alfredo Iglesias"
ManipularVarios(loAdmin)
Dim loFac As New Factura()
loFac.pdtFecha = "25/2/2002"
loFac.piImporte = 475
ManipularVarios(loFac)
Console.Read()
End Sub
Public Sub ManipularVarios(ByVal loUnObjeto As Object)
' obtenemos información sobre el tipo del objeto
Dim loTipoObj As Type
loTipoObj = loUnObjeto.GetType()
' comprobamos qué tipo de objeto es,
' y en función de eso, ejecutamos el
' método adecuado
Select Case loTipoObj.Name
Case "Empleado", "Administrativo"
CType(loUnObjeto, Empleado).VerDatos()
Case "Factura"
CType(loUnObjeto, Factura).Emitir()
End Select
End Sub
End Module
Public Class Administrativo
Inherits Empleado
Public pdtFHAlta As Date
Public Overrides Sub VerDatos()
Console.WriteLine("DATOS DEL ADMINISTRATIVO")
Console.WriteLine("==================")
Console.WriteLine("Código: {0}", Me.piID)
Console.WriteLine("Nombre: {0}", Me.psNombre)
End Sub
Public Function MesAlta()
Return Format(Me.pdtFHAlta, "MMMM")
End Function
End Class
Código fuente 283

Pero ¿cómo podríamos ejecutar el método particular MesAlta( ) de Administrativo, que no se encuentra en Empleado?, pues creando en la estructura Select...Case, un caso particular que compruebe cuándo estamos tratando con un objeto Administrativo. Veámoslo en el Código fuente 284.
Public Sub ManipularVarios(ByVal loUnObjeto As Object)
' obtenemos información sobre el tipo del objeto
Dim loTipoObj As Type
loTipoObj = loUnObjeto.GetType()
' comprobamos qué tipo de objeto es,
' y en función de eso, ejecutamos el
' método adecuado
Select Case loTipoObj.Name
Case "Empleado"
CType(loUnObjeto, Empleado).VerDatos()
Case "Administrativo" ' <-- añadimos este caso a la estructura
CType(loUnObjeto, Administrativo).VerDatos()
Console.WriteLine("El administrativo comenzó en {0}", _
CType(loUnObjeto, Administrativo).MesAlta())
Case "Factura"
CType(loUnObjeto, Factura).Emitir()
End Select
End Sub
Código fuente 284

Elementos compartidos e interfaces - II

Conociendo ya el tipo de objeto con el que tratamos, utilizaremos la función CType( ), que realiza un moldeado de la variable que contiene el objeto hacia un tipo determinado, y nos permite acceder a los elementos del objeto. 
El lector puede argumentar que no sería necesario el uso de CType(), y en efecto es así; podríamos haber utilizado directamente la variable, situando a continuación el método a ejecutar. Esta técnica, no obstante, tiene el inconveniente de que utiliza enlace tardío para acceder al objeto. 
CType( ) sin embargo, tiene la ventaja de que opera bajo enlace temprano, con lo cuál, el rendimiento en ejecución es mayor. Veamos el código cliente que accedería a estas clases en el Código fuente 282.

Module Module1
Public Sub Main()
Dim loEmple As New Empleado()
loEmple.piID = 58
loEmple.psNombre = "Elena Peral"
ManipularVarios(loEmple)
Dim loFac As New Factura()
loFac.pdtFecha = "25/2/2002"
loFac.piImporte = 475
ManipularVarios(loFac)
Console.Read()
End Sub
Public Sub ManipularVarios(ByVal loUnObjeto As Object)
' obtenemos información sobre el tipo del objeto
Dim loTipoObj As Type
loTipoObj = loUnObjeto.GetType()
' comprobamos qué tipo de objeto es,
' y en función de eso, ejecutamos el
' método adecuado
Select Case loTipoObj.Name
Case "Empleado"
CType(loUnObjeto, Empleado).VerDatos()
Case "Factura"
CType(loUnObjeto, Factura).Emitir()
End Select
End Sub
End Module
Código fuente 282

Elementos compartidos e interfaces - I

Comprobación del tipo de un objeto y moldeado (casting)

En algunas circunstancias, puede ser útil codificar un procedimiento que reciba como parámetro un objeto genérico, y dependiendo del tipo del objeto, ejecutar ciertos métodos. Si tipificamos un parámetro como un objeto genérico, es decir, de tipo Object, necesitamos implementar dentro del procedimiento un mecanismo que, en primer lugar, compruebe a qué tipo pertenece el objeto, y por otra parte, acceda adecuadamente a su lista de miembros. Como ejemplo consideremos el siguiente caso: creamos una clase Empleado y otra Factura, las cuales vemos en el Código fuente 281.

Public Class Empleado
Public piID As String
Public psNombre As String
Public Overridable Sub VerDatos()
Console.WriteLine("Código de empleado: {0}, nombre: {1}", _
Me.piID, Me.psNombre)
End Sub
End Class
Public Class Factura
Public pdtFecha As Date
Public piImporte As Integer
Public Sub Emitir()
Console.WriteLine("Se procede a generar la siguiente factura:")
Console.WriteLine("Fecha de factura: {0}", Me.pdtFecha)
Console.WriteLine("Importe de la factura: {0}", Me.piImporte)
End Sub
End Class
Código fuente 281
A continuación, necesitamos un procedimiento al que podamos pasar indistintamente un objeto Empleado o Factura. Dentro de dicho procedimiento, al que denominaremos ManipularVarios( ), y que llamaremos desde Main( ), comprobaremos el tipo de objeto llamando al método 

GetType( ), que implementan todos los objetos del entorno, debido a que es un método de la clase Object, y como ya sabemos, todas las clases heredan implícitamente de Object. GetType( ) devuelve un objeto de la clase Type. Esta clase es de una enorme utilidad, ya que nos proporciona toda la información relativa al tipo del objeto. Para nuestro problema particular, interrogaremos a la propiedad Name del objeto, que nos devolverá una cadena con el nombre de la clase a que pertenece el objeto.

Clases abstractas o no instanciables - II

Debemos tener en cuenta que los miembros abstractos sólo tienen sentido si son declarados en clases abstractas. Por tal motivo, sólo podremos crear métodos con MustOverride en clases que hayan sido definidas como MustInherit. 
En lo que respecta al polimorfismo conseguido a través de clases abstractas, podemos crear un procedimiento que reciba como parámetro tipificado como clase abstracta, de forma que en función del objeto pasado, y que debe ser de un tipo derivado de la clase abstracta, el comportamiento será diferente en cada caso. Veámoslo en el Código fuente 280.

Module Module1
Public Sub Main()
'....
End Sub
' el objeto que reciba este procedimiento será
' de cualquiera de las clases que hereden de
' Empleado y ejecutará la implementación del método
' VerDatos() que tenga dicho objeto
Public Sub MostrarInformacion(ByVal loEmple As Empleado)
loEmple.VerDatos()
End Sub
End Module
Código fuente 280

Clases abstractas o no instanciables - I

Una clase abstracta es aquella que no permite la instanciación directa de objetos a partir de ella, siendo necesario una clase derivada para acceder a sus miembros. Una clase concreta es el tipo de clase que venimos utilizando hasta el momento, desde la cuál, podemos instanciar objetos. 
Aunque en una clase abstracta podemos escribir un método constructor, sólo será accesible desde el constructor de la subclase. 
Para definir una clase abstracta utilizaremos la palabra clave MustInherit en el momento de su declaración, como muestra el Código fuente 278.

Public MustInherit Class Empleado
Código fuente 278
Dentro de una clase abstracta podemos implementar propiedades y métodos, en la forma que hemos visto hasta el momento. Adicionalmente, podemos obligar a que determinados miembros sean sobrescritos por la clase heredada; son los denominados miembros abstractos, y se declaran usando la palabra clave MustOverride, como vemos en el Código fuente 279.

Module Module1
Public Sub Main()
Dim loAdmin As New Administrativo()
loAdmin.piID = 789
loAdmin.psNombre = "Pedro Pinares"
Console.WriteLine("Nombre en mayúsculas del administrativo: {0}", _
loAdmin.NombreMay)
loAdmin.pdtFHAlta = "8/10/01"
loAdmin.MesesActivo()
Console.Read()
End Sub
End Module
' clase abstracta,
' no podemos crear objetos Empleado
Public MustInherit Class Empleado
Public piID As Integer
Public psNombre As String
Public pdtFHAlta As Date
Public ReadOnly Property NombreMay() As String
Get
Return UCase(Me.psNombre)
End Get
End Property
' método abstracto;
' este método debe ser sobrescrito
' por la clase derivada
Public MustOverride Sub MesesActivo()
Public Sub VerDatos()
Console.WriteLine("Información sobre el empleado." & _
" ID:{0} - Nombre:{1} - Fecha de alta:{2}", _
Me.piID, Me.psNombre, Me.pdtFHAlta)
Console.WriteLine()
End Sub
End Class
' desde esta clase tendremos acceso
' a los miembros de la clase Empleado
Public Class Administrativo
Inherits Empleado
' en esta clase sobrescribimos este método
' declarado como abstracto en la clase abstracta
Public Overrides Sub MesesActivo()
Console.WriteLine("Entró en el mes de {0}", _
Format(Me.pdtFHAlta, "MMMM"))
Console.WriteLine("El número de meses que lleva es: {0}", _
DateDiff(DateInterval.Month, Me.pdtFHAlta, Now))
End Sub
Public Overrides Sub VerDatos()
'....
'....
End Sub
End Class
Código fuente 279

Clases selladas o no heredables

Toda clase que declaremos en nuestro código es heredable por defecto; esto supone un elevado grado de responsabilidad, en el caso de que diseñemos una clase pensando en que pueda ser utilizada por otros programadores que hereden de ella. Si en un determinado momento, necesitamos hacer cambios en nuestra clase, dichos cambios afectarán a las clases derivadas que hayan sido creadas. 
Por dicho motivo, si no queremos que nuestra clase pueda ser heredada por otras, debemos declararla de forma que no permita herencia; a este tipo de clase se le denomina clase no heredable o sellada (sealed). Para definir una clase no heredable, debemos utilizar la palabra clave NotInheritable en el momento de su declaración. 
En la Figura 121 hemos creado la clase Fichero como no NotInheritable, por ello, cuando a continuación declaramos la clase FiTexto e intentamos que herede de Fichero, se mostrará un mensaje de error en el editor de código, indicándonos que no es posible establecer esta relación de herencia puesto que Fichero es una clase sellada.
Figura 121. No es posible heredar de una clase NotInheritable.

Herencia y métodos constructores - II

Podemos no obstante, evitar la obligación de escribir un constructor en la clase derivada, si en la clase padre creamos un constructor sin parámetros. Como ya sabemos, la sobrecarga de métodos nos permite escribir varios métodos con el mismo nombre y diferente lista de parámetros. Modifiquemos para ello la clase Empleado como muestra el Código fuente 277.

Public Class Empleado
Public piID As Integer
Public psNombre As String
Public piSalario As Integer
' constructor parametrizado
Public Sub New(ByVal lsNombre As String)
Me.psNombre = lsNombre
End Sub
' constructor sin parámetros
Public Sub New()
psNombre = "hola"
End Sub
End Class
Public Class Administrativo
Inherits Empleado
' al disponer en la clase base de
' un constructor normal, ya no hay
' necesidad de crear un constructor
' en esta clase derivada
End Class
Código fuente 277

Finalmente, debemos apuntar dos reglas que debe cumplir todo método constructor de una subclase que llame al constructor de su clase base: en primer lugar, el constructor base debe ser llamado en la primera línea del constructor derivado; en segundo lugar, el constructor base sólo puede ser llamado una vez desde el constructor derivado.

Herencia y métodos constructores - I

Podemos crear una clase base que implemente un constructor y una subclase sin él. En esta situación, cuando instanciemos un objeto de la subclase, se llamará implícitamente al constructor de la clase base para ejecutar el código de inicialización. También es posible crear el constructor sólo en la clase derivada. 
Si ambas clases disponen de un constructor, en primer lugar se ejecutará el constructor de la clase base y después el de la clase derivada. Realmente, el primer constructor ejecutado corresponde a la clase Object, y sucesivamente, se irán ejecutando todos los constructores de la jerarquía de clases hasta llegar a la clase que originó la llamada. El problema sobreviene cuando en la clase base creamos un constructor parametrizado, ya que ello obliga a sus clases derivadas a crear también un método constructor dentro del cuál se haga una llamada al constructor de la clase base. Para llamar explícitamente a un método de la clase base desde una subclase utilizaremos la palabra clave MyBase, que contiene una referencia hacia la clase padre. 
Veamos un ejemplo, en el Código fuente 276 se crea una clase padre Empleado y la subclase Administrativo. Puesto que Empleado dispone de un constructor parametrizado, en Administrativo debemos crear también un constructor, y dentro de él llamar en primer lugar al constructor base.

Public Class Empleado
Public piID As Integer
Public psNombre As String
Public piSalario As Integer
' constructor parametrizado
Public Sub New(ByVal lsNombre As String)
Me.psNombre = lsNombre
End Sub
End Class
Public Class Administrativo
Inherits Empleado
' constructor normal
Public Sub New()
' llamada al constructor
' de la clase base
MyBase.New("Juan")
Me.piSalario = 100
End Sub
End Class
Código fuente 276

Ocultamiento de miembros de una clase - II

Cuando en una clase hija creamos un método con el mismo nombre y parámetros que en la clase padre, el compilador realiza un ocultamiento implícito, aunque genera un aviso, recomendando que declaremos el método de la clase hija con Shadows. Veamos el Código fuente 274.

Public Class Empleado
'....
Public Sub Sueldo()
' aquí mostramos en consola el importe del sueldo formateado
Console.WriteLine("El sueldo es {0}", Format(Me.Salario, "#,#.##"))
Console.ReadLine()
End Sub
'....
End Class
Public Class Administrativo
'....
' si aquí no utilizáramos Shadows, el entorno
' marcaría este método con un aviso
Public Shadows Sub Sueldo()
' aquí incrementamos el valor actual de la propiedad Salario
Me.Salario += 250
End Sub
'....
End Class
Código fuente 274
Por otra parte, si aplicamos el ocultamiento en la sobre-escritura, el comportamiento del objeto se verá profundamente afectado. La mejor situación para comprobar este particular consiste en declarar una variable de la clase base y asignarle un objeto de una clase heredada. A pesar de que, como hemos comentado anteriormente, la sobre-escritura se basa en el enlace tardío, si ocultamos un miembro de la clase derivada, forzaremos al objeto a dirigirse a la versión de dicho miembro existente en la clase padre. 
El ejemplo del Código fuente 275 muestra este caso. En él creamos nuestras dos clases habituales, Empleado y Administrativo, relacionadas mediante herencia, con un método sobrescrito en ambas, que tiene la particularidad de que la versión existente en la clase derivada está oculto con Shadows. Esto hará que al instanciar un objeto de la clase hija, y pasárselo a una variable referenciada hacia la clase padre, la llamada al método sea desviada hacia la implementación existente en la clase padre, en lugar de a la clase derivada como sería su comportamiento habitual.

Module Module1
Sub Main()
Dim loPersona As Empleado
loPersona = New Administrativo()
loPersona.psNombre = "Juan"
' estamos utilizando sobre-escritura,
' por lo que el enlace tardío emplea el objeto
' que hay dentro de la variable y no la
' referencia de la variable;
' al estar oculta con Shadows la implementación
' del método MostrarNombre() en la clase Administrativo
' se ejecuta dicho método pero de la clase Empleado
loPersona.MostrarNombre()
Console.ReadLine()
End Sub
End Module
Public Class Empleado
Public psNombre As String
Public pdtFHAlta As Date
Public Overridable Sub MostrarNombre()
Console.WriteLine("El nombre del empleado es {0}", _
Me.psNombre)
End Sub
End Class
Public Class Administrativo : Inherits Empleado
' ocultamos este método
Public Shadows Sub MostrarNombre()
Console.WriteLine("Nombre del empleado")
Console.WriteLine("===================")
Console.WriteLine(UCase(Me.psNombre))
End Sub
End Class
Código fuente 275
La Tabla 24 muestra, al utilizar sobre-escritura y ocultamiento, la clase de la cuál será ejecutado el método, en función de la referencia de la variable y el tipo de objeto.

Ocultamiento de miembros de una clase - I

Esta técnica consiste en crear dentro de una clase derivada, miembros con el mismo nombre (y firma, en el caso de métodos) que los existentes en la clase base, pero ocultando el acceso a los miembros de la clase base para los objetos instanciados de la subclase. Utilizaremos la palabra clave Shadows, en la declaración de aquellos miembros a esconder.
Cuando aplicamos el ocultamiento sobre una subclase que tiene métodos sobrecargados en la clase base, dichos métodos sobrecargados quedarán inaccesibles para la clase derivada. Como ejemplo, en el Código fuente 273, la clase Empleado implementa dos versiones sobrecargadas del método Sueldo( ), mientras que la clase hija Administrativo también tiene el método Sueldo( ), pero al declararse con Shadows, impide que los objetos de tipo Administrativo ejecuten los métodos Sueldo( ) de la clase Empleado.

Module Module1
Sub Main()
Dim loAdmin As New Administrativo()
Dim ldbImporte As Double
Dim lsFecha As String
loAdmin.Salario = 925.86
ldbImporte = loAdmin.Sueldo(80, "Viajes")
' los siguientes métodos están ocultos
' desde este objeto y se produce un error al llamarlos
loAdmin.Sueldo()
lsFecha = loAdmin.Sueldo(5)
End Sub
End Module
Public Class Empleado
Private mdbSalario As Double
Public Property Salario() As Double
Get
Return mdbSalario
End Get
Set(ByVal Value As Double)
mdbSalario = Value
End Set
End Property
' métodos sobrecargados
Public Overloads Sub Sueldo()
' aquí mostramos en consola el importe del sueldo formateado
Console.WriteLine("El sueldo es {0}", Format(Me.Salario, "#,#.##"))
Console.ReadLine()
End Sub
Public Overloads Function Sueldo(ByVal liDia As Integer) As String
' aquí mostramos la fecha del mes actual
' en la que se realizará la transferencia
' del sueldo al banco del empleado
Dim ldtFechaActual As Date
Dim lsFechaCobro As String
ldtFechaActual = Now()
lsFechaCobro = CStr(liDia) & "/" & _
CStr(Month(ldtFechaActual)) & "/" & _
CStr(Year(ldtFechaActual))
Return lsFechaCobro
End Function
End Class
Public Class Administrativo
Inherits Empleado
' este método ensombrece/oculta a los sobrecargados
' de la clase base Empleado
Public Shadows Function Sueldo(ByVal ldbImporteIncentivo As Double, _
ByVal lsTipoIncentivo As String) As Double
' aquí calculamos la cantidad de incentivo
' que se añadirá al sueldo del empleado,
' en función del tipo de incentivo
Dim ldbIncentivo As Double
' según el tipo de incentivo,
' se descuenta un importe
' de la cantidad del incentivo
Select Case lsTipoIncentivo
Case "Viajes"
ldbIncentivo = ldbImporteIncentivo - 30
Case "Extras"
ldbIncentivo = ldbImporteIncentivo - 15
End Select
Return ldbIncentivo
End Function
End Class
Código fuente 273

La palabra clave MyClass

Ante una situación de sobre-escritura de métodos en una clase base y heredada, la palabra clave MyClass, nos permite, alterar el comportamiento por defecto en la llamada al método, forzando la ejecución del que existe en la clase base. Expliquemos mejor este aspecto con un ejemplo ilustrativo. 
Creamos la clase Empleado y su clase hija Administrativo, y en ambas escribimos el método VerFecha( ) utilizando sobre-escritura; este método va a ser llamado a su vez desde el método MostrarDatos( ), que se encuentra en la clase Empleado con la siguiente sintaxis.

Me.VerFecha()

Si desde el código cliente instanciamos un objeto de Administrativo, al ejecutar MostrarDatos( ), la versión de VerFecha( ) ejecutada será la que se encuentra en el código de la clase Administrativo. ¿Pero y si necesitamos ejecutar la versión de VerFecha( ) que está en el código de la clase Empleado?, pues es posible utilizando la palabra clave MyClass. Veamos este ejemplo al completo en el Código fuente 272.

Module Module1
Sub Main()
Dim oAdmin As New Administrativo()
oAdmin.Nombre = "Alfredo"
oAdmin.FechaAlta = DateTime.Today
oAdmin.MostrarDatos()
Console.ReadLine()
End Sub
End Module
Public Class Empleado
Public Nombre As String
Public FechaAlta As Date
Public Sub MostrarDatos()
Console.WriteLine("Datos del empleado")
Console.WriteLine("Nombre: {0}", Me.Nombre)
Me.VerFecha() ' ejecuta VerFecha de clase Administrativo
MyClass.VerFecha() ' ejecuta VerFecha de clase Empleado
End Sub
Public Overridable Sub VerFecha()
Console.WriteLine("Fecha alta completa: {0}", Me.FechaAlta)
End Sub
End Class
Public Class Administrativo
Inherits Empleado
Public Overrides Sub VerFecha()
Console.WriteLine("Fecha alta -sólo nombre mes- : {0}",
Me.FechaAlta.ToString("MMMM"))
End Sub
End Class
Código fuente 272
Como podemos suponer, MyClass fuerza a ejecutar la implementación del método que existe en la clase desde la que se hace la llamada a dicho método.

Diferencias entre sobrecarga y sobre-escritura en base al tipo de enlace - II

Pasando seguidamente a la sobre-escritura, escribiremos en la clase padre el método MostrarNombre( ), y lo sobrescribiremos en la clase hija. Instanciaremos después un objeto Administrativo y lo asignaremos a la variable tipificada como Empleado. Debido a que el enlace tardío se basa en el tipo del objeto que contiene la variable, y no en el tipo de la variable, al llamar al método MostrarNombre( ), se ejecutará la versión de la clase Administrativo. Veamos el Código fuente 271.

Module Module1
Sub Main()
Dim loPersona As Empleado
loPersona = New Administrativo()
loPersona.psNombre = "Juan García"
' como la sobre-escritura utiliza enlace tardío,
' se basa en el objeto que contiene la variable y
' no en el tipo de dato de la variable, se ejecuta
' la versión del método MostrarNombre() que está
' en la clase Administrativo, ya que el objeto
' que contiene la variable loPersona es una
' instancia de Administrativo
loPersona.MostrarNombre()
Console.ReadLine()
End Sub
End Module
Public Class Empleado
Public psNombre As String
Public pdtFHAlta As Date
Public Overridable Sub MostrarNombre()
Console.WriteLine("El nombre del empleado es {0}", _
Me.psNombre)
End Sub
End Class
Public Class Administrativo : Inherits Empleado
Public Overrides Sub MostrarNombre()
Console.WriteLine("Nombre del empleado")
Console.WriteLine("===================")
Console.WriteLine(UCase(Me.psNombre))
End Sub
End Class
Código fuente 271
La Tabla 23 muestra, al utilizar sobre-escritura, la clase de la cuál será ejecutado el método, en función de la referencia de la variable y el tipo de objeto.
Tabla 23. Método ejecutado mediante enlace tardío bajo sobre-escritura.
Debido al hecho de que los miembros sobrescritos emplean enlace tardío, otra de las denominaciones que se utiliza para ellos es la de método virtual.

Diferencias entre sobrecarga y sobre-escritura en base al tipo de enlace - I

La otra diferencia entre sobrecarga y sobre-escritura consiste en el tipo de enlace que utilizan. Mientras que la sobrecarga se basa en enlace temprano, la sobre-escritura emplea enlace tardío. 
El mejor modo de comprobar este punto, consiste en declarar una variable con un tipo perteneciente a una clase base, pero asignándole un objeto correspondiente a una clase heredada. 
Por ejemplo, en el caso de la sobrecarga, creamos las ya conocidas clases Empleado y Administrativo, escribiendo el método VerAlta( ), sobrecargado en cada una de ellas.
A continuación declaramos una variable de tipo Empleado, pero instanciamos un objeto de la clase Administrativo y lo asignamos a la variable. Debido a que el enlace temprano se basa en el tipo de la variable y no en el objeto que contiene, el método VerAlta( ) al que podremos acceder será el que se encuentra en la clase Empleado. Veamos el Código fuente 270.

Module Module1
Sub Main()
Dim loPersona As Empleado
loPersona = New Administrativo()
loPersona.psNombre = "Juan García"
loPersona.pdtFHAlta = "15/1/2002"
' como la sobrecarga utiliza enlace temprano,
' se basa en el tipo de la variable y no
' en el objeto que se asigna a esa variable,
' por ello sólo es visible la implementación
' del método que hay en la clase Empleado
loPersona.VerAlta()
' si intentamos ejecutar el método VerAlta()
' que recibe una cadena, se producirá el siguiente error:
' "Demasiados argumentos para 'Public Sub VerAlta()'."
loPersona.VerAlta("Mes") ' <-- error
Console.ReadLine()
End Sub
End Module
Public Class Empleado
Public psNombre As String
Public pdtFHAlta As Date
' mostrar la fecha de alta al completo
Public Sub VerAlta()
Console.WriteLine("El empleado {0} se incorporó el {1}", _
Me.psNombre, Me.pdtFHAlta)
End Sub
End Class
Public Class Administrativo : Inherits Empleado
' mostrar sólo una parte de la fecha de alta
' según el parámetro pasado
Public Overloads Sub VerAlta(ByVal lsParteFecha As String)
Dim lsValorFecha As String
Select Case lsParteFecha
Case "Mes"
lsValorFecha = Format(Me.pdtFHAlta, "MMMM")
Case "DiaSemana"
lsValorFecha = Format(Me.pdtFHAlta, "dddd")
End Select
Console.WriteLine("Empleado {0}", Me.psNombre)
Console.WriteLine("Incorporado {0}", lsValorFecha)
End Sub
End Class
Código fuente 270