Herencia

16/11/2005 - 19:22 por Silviall | Informe spam
Hola a todos,

Estoy creando controles mediante herencia. Tengo uno control base y un
control para oracle y otro para sqlserver. El problema viene cuando declaro
la variable da (OracleDataadapter o SqlDataAdapter), ya que no puedo
declarar la variable en la base y tengo que declararla en las subclases.
Pero a lo mejor tengo un metodo en la clase base que utiliza esta variable
que en la clase base la declaro como Object y en las subclases hago un
shadows al tipo. Pero en este método este objeto no tiene nada es nothing
cuando estoy ejecutando la aplicación y el metodo no esta implementado en la
subclase y salta a la implementación de la clase base? Qué hago mal? Estos
métodos los tengo que pasar dentro de las subclases??

Saludos,

Sílvia.

Preguntas similare

Leer las respuestas

#1 Tristan
16/11/2005 - 22:24 | Informe spam
Silviall, en realidad yo te recomendaría no definir en la base el objeto
como Object sino como DbDataAdapter. Todos los objetos de tipo DataAdapter
han de ser necesariamente de esa clase común. DbDataAdapter dispone de casi
todos los miembros necesarios para manipular el DataAdapter de forma
genérica, sin necesidad de especializar.

En cuando a Shadows, hay que tener mucho cuidado con esa clausula, puesto
que sólo está prevista como parche. Shadows esconde miembros de la clase
base sólo cuando se accede desde la clase que la implementa o descendientes,
pero no los esconde cuando se accede desde una clase base (polimorfismo).
Shadows está pensado para dar a los herederos la posibilidad de cambiar
aspectos de la clase base, pero sin afectar a las aplicaciones antiguas que
esperan el comportamiento antiguo.

No sé si me explico por que es un poco enrevesado. Espero explicarlo mejor
con un ejemplo:

Imagina que tienes una clase derivada de TextBox, TuTextBox. En esta
reintroduces (no sobreescribes) la propiedad Text, mediante Shadows, de
forma que devuelva el texto "Shadows".

TuTextBox tb1 = new TuTextBox();
TextBox tb2 = tb1 'tb1 y tb2 apuntan al mismo objeto
tb2.Text = "Propiedad original";
msgbox(tb1.Text) '<= Muestra "Shadows".
msgbox(tb2.Text) '<= Muestra "Propiedad original".


Juan Carlos Badiola
MVP - C#
Respuesta Responder a este mensaje
#2 Silviall
17/11/2005 - 13:41 | Informe spam
Qué utilizo en lugar de Shadows??

Gracias Juan Carlos,

Silvia.

"Tristan" escribió en el mensaje
news:
Silviall, en realidad yo te recomendaría no definir en la base el objeto
como Object sino como DbDataAdapter. Todos los objetos de tipo DataAdapter
han de ser necesariamente de esa clase común. DbDataAdapter dispone de
casi todos los miembros necesarios para manipular el DataAdapter de forma
genérica, sin necesidad de especializar.

En cuando a Shadows, hay que tener mucho cuidado con esa clausula, puesto
que sólo está prevista como parche. Shadows esconde miembros de la clase
base sólo cuando se accede desde la clase que la implementa o
descendientes, pero no los esconde cuando se accede desde una clase base
(polimorfismo). Shadows está pensado para dar a los herederos la
posibilidad de cambiar aspectos de la clase base, pero sin afectar a las
aplicaciones antiguas que esperan el comportamiento antiguo.

No sé si me explico por que es un poco enrevesado. Espero explicarlo mejor
con un ejemplo:

Imagina que tienes una clase derivada de TextBox, TuTextBox. En esta
reintroduces (no sobreescribes) la propiedad Text, mediante Shadows, de
forma que devuelva el texto "Shadows".

TuTextBox tb1 = new TuTextBox();
TextBox tb2 = tb1 'tb1 y tb2 apuntan al mismo objeto
tb2.Text = "Propiedad original";
msgbox(tb1.Text) '<= Muestra "Shadows".
msgbox(tb2.Text) '<= Muestra "Propiedad original".


Juan Carlos Badiola
MVP - C#

Respuesta Responder a este mensaje
#3 Tristan
17/11/2005 - 16:02 | Informe spam
No creo que necesites utilizar nada en lugar de Shadows. Define en la base
el objeto como DBDataAdapter. Podrás devolver a través de ella cualquier
objeto DataAdpater espécífico, por ejemplo SqlDataAdapter. DBDataAdapter te
permitirá realizar directamente la mayor parte de operaciones necesarias,
Fill, Update, FillSchema, etc...

Sólo habrá unas pocas cosas que no podrás hacer con el DataAdapter genérico
que si podrás hacer mediante el DataAdapter específico. Para esos casos
dispondrás de varias soluciones:

Downcasting => ctype(dataAdapterGenérico, SqlDataAdapter)

Shadows. Con el inconveniente de que Shadows no sirve para acceder de forma
polimórfica.

Crear una propiedad con distinto nombre a la original, SqlDataAdapter en la
clase de Sql Server, que devolverá el tipo específico.

En general si lo que quieres es crear código independiente del proveedor, lo
que tienes que hacer es trabajar sobre las clases o interfaces genéricas.

dim da as DBDataAdapter = new SqlDataAdapter(...) '*** Nota
da.Fill(...)
...
da.Update(...)

dim con as IDBConnection = new SqlConnection(...)
con.Open()
...
con.Close()


*** Nota:
El único código dependiente del proveedor es la instanciación del
DataAdapter, Connection, etc...
Puedes utilizar el patrón factoría para lograr total independencia del SGBD.
Creas una clase que devuelva objetos del proveedor específico en función de
un parámetro. Si tienes dudas sobre esto último no dudes en preguntar.

Juan Carlos Badiola
MVP - C#
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida