POO y VB

No es por complicar sino que son otros modificadores que pueden aplicarse a
los metodos. Shadows indica que se va a redefinir un metodo de la clase
padre pero sin sobreescribirlo y no es propio de VB ya que C# tiene su
equivalente: new. En cuanto a la inclusion de MyClass te permite llamar a la
version de un metodo definido en la misma clase en lugar de una version
sobreescrita por una subclase. Yo no le encuentro un uso practico, pero de
necesitarlo ahi esta para usarlo.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Gracias Eduardo:

De todas formas, cuando comience a programar en serio con VB, evitaré
en la medida de lo posible las palabras Shadows y MyClass ;-)

Eduardo A. Morcillo [MS MVP VB] ha escrito:

No es por complicar sino que son otros modificadores que pueden aplicarse a
los metodos. Shadows indica que se va a redefinir un metodo de la clase
padre pero sin sobreescribirlo y no es propio de VB ya que C# tiene su
equivalente: new. En cuanto a la inclusion de MyClass te permite llamar a la
version de un metodo definido en la misma clase en lugar de una version
sobreescrita por una subclase. Yo no le encuentro un uso practico, pero de
necesitarlo ahi esta para usarlo.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Hola Sergio y demas contertulios :)

Yo tambien soy nuevo con esto de VB.NET y OOP, pero precisamente 'creo' que
MyClass no es un objeto a obviar. Es mas, en el tipico ejemplo de
programacion y herencia, te muestra el 'problema' de no usar MyClass. A ver
si lo consigo reproducir a ojimetro :):

Class clsA
Public Overridable Function fA()
Return "fA: desde clsA"
End Function

Public Function fB()
Return fA() ''' Llamando a una fA() que 'puede' no
ser de clsA
End Function

Public Function fC()
Return MyClass.fA() ''' Llamando a fA() de clsA.
End Function
End Class

Class clsB
Inherits clsA
Public Overrides Function fA()
Return "fA: desde clsB"
End Function
End Class

Dim objB As New clsB

MsgBox objB.fB ''''fA: desde clsB'
MsgBox objB.fC ''''fA: desde clsA'

Nota: No tengo VS.NET, asi que la sintaxis puede no ser la correcta.

Ya se que el ejemplo esta cogido por los pelos, pero bueno es saberlo :-)

Saludos

"Sergio" escribió en...
Gracias Eduardo:

De todas formas, cuando comience a programar en serio con VB, evitaré
en la medida de lo posible las palabras Shadows y MyClass ;-)

Eduardo A. Morcillo [MS MVP VB] ha escrito:

No es por complicar sino que son otros modificadores que pueden aplicarse

a

los metodos. Shadows indica que se va a redefinir un metodo de la clase
padre pero sin sobreescribirlo y no es propio de VB ya que C# tiene su
equivalente: new. En cuanto a la inclusion de MyClass te permite llamar a

la

version de un metodo definido en la misma clase en lugar de una version
sobreescrita por una subclase. Yo no le encuentro un uso practico, pero de
necesitarlo ahi esta para usarlo.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

http://mvp.support.microsoft.com/pr...04EF5A4191
C

Hola Luis:

Tu ejemplo está bien (ya me gustaría a mi sin IDE escribir código
sin errores) y es muy claro, pero...

Imagina que tu no eres el creador de la clase clsA, sino que eres
cliente (y no tienes acceso al código fuente) y asumes que si
sobreescribes fA (que además el creador de clase pensó que sería
buena idea porque la declaró como "overridable"), tu clase derivada
siempre llamará a tu nueva versión de fA (que has sobreescrito porque
la implementación original no te era válid), pero sorpresa en
algún momento oscuro del programa ... se ejecuta fA de la clase base y
no el que tu querias... bueno... vale... ¿no sería mejor utilizar
MyBase.fA cuando yo quiera o evitar que se pueda sobreescribir el
método si que es un procedimiento "vital"?

Quiero decir que llevas razón en que ahí esta para cuando se
necesite, pero que se me ocurren (como a ti) pocos casos (claro, que
tampoco programo mucho con POO y estoy empezando ahora)

Si no me he explicado muy bien, lo siento, tanto objeto por aquí y por
allí terminan por atorarme.

Un saludo.

Hola Sergio:

Yo estoy igual que tu, al principio muchos conceptos y te lias, pero te has
explicado bien y he entendido lo que querias decir. Es dificil encontrar
usos/utilidades de MyClass, pero se pueden encontrar ;-)

Yo creo un metodo SORT maravilloso, rapido y optimizado para mi clase clsA.
Pero me interesa 'permitir' sobreescribirlo (overridable) para que si
alguien hereda mi clase, puede (o no) necesitar modificar la manera de
ordenar el objeto (puesto que puede tener mas propiedades, y no quiere tener
dos metodos: Sort y SortNuevo). Pero desde mi clase (clsA), yo cuando llame
al metodo SORT, quiero que se ejecute el mio, puesto que es el mas
maravilloso y el mas rapido :) => MyClass.Sort()

Esto es lo que se me ha ocurrido :), ahora falta que alguien que haya
programado con objetos 'realmente' se haya encontrado con un problema
parecido.

Saludos

Luis

"Sergio" escribió en...
Hola Luis:

Tu ejemplo está bien (ya me gustaría a mi sin IDE escribir código
sin errores) y es muy claro, pero...

Imagina que tu no eres el creador de la clase clsA, sino que eres
cliente (y no tienes acceso al código fuente) y asumes que si
sobreescribes fA (que además el creador de clase pensó que sería
buena idea porque la declaró como "overridable"), tu clase derivada
siempre llamará a tu nueva versión de fA (que has sobreescrito porque
la implementación original no te era válid), pero sorpresa en
algún momento oscuro del programa ... se ejecuta fA de la clase base y
no el que tu querias... bueno... vale... ¿no sería mejor utilizar
MyBase.fA cuando yo quiera o evitar que se pueda sobreescribir el
método si que es un procedimiento "vital"?

Quiero decir que llevas razón en que ahí esta para cuando se
necesite, pero que se me ocurren (como a ti) pocos casos (claro, que
tampoco programo mucho con POO y estoy empezando ahora)

Si no me he explicado muy bien, lo siento, tanto objeto por aquí y por
allí terminan por atorarme.

Un saludo.