problema con HERENCIA

21/05/2007 - 20:56 por Daniel Maldonado | Informe spam

Estimados. estoy estudiando C#.net y estoy comenzando mi larga y tediosa
curva de aprendizaje. Si bien no será tan dificil dado que vengo desde C++
con POO. pero estuve haciendo esta prueba de herencia y el compilador me
tira el siguiente error. Pongo el código para que vean la simplicidad del
ejemplo.

Defino una clase MAMIFEROS y luego una clase HUMANOS como herencia de
MAMIFEROS y vean el problema principalmente con el constructor de la clase
HUMANOS.

Me dice: " Ninguna sobrecarga para el método MAMIFEROS acepta "0" argumentos
".

Cual sera el error conceptual que estoy cometiendo ???.

class Mamiferos

{

public string strNombreDeEspecie;

public int intTipoDeEspecie;

public Mamiferos(string n, int t)

{

this.strNombreDeEspecie = n;

this.intTipoDeEspecie = t;

}

}

****************************************************************************
********************

****************************************************************************
********************

class Humanos : Mamiferos

{

public string strRazaDeHumano;

public int intCantidadHumanos;

public Humanos (string r, int c)

{

this.strNombreDeEspecie = r;

this.intCantidadHumanos = c;

}

}

Siga el debate

40 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#16 Alberto Poblacion

22/05/2007 - 09:47 | Informe spam

"RFOG" wrote in message
news:

A mayor abundamiento, hay otro caso más en que tampoco son
compatibles los campos con las propiedades: Un campo se puede pasar como
argumento tipo "ref" a una función. Si sustituyes el campo por una
propiedad, deja de ser compatible a nivel de código fuente porque la
propiedad no puede pasarse de esa manera.

Yap, pero el único propósito de pasar una variable miembro a una función
es la de pasársela a un método de otra clase (porque desde tu propia clase
deberías acceder directamente a la variable miembro)... lo que viola todos
los paradigmas de la orientación a objetos.

No entiendo nada. ¿Qué tiene eso que ver con lo que yo digo?:

class MiClase
{
public string campo;
}
...
class OtraClase
{
void Funcion1(ref string x)
{...}
void HacerAlgo()
{
MiClase c = new MiClase();
Funcion1(ref c.campo);
}
}

Aquí vemos que si en "Miclase" se cambia "campo" por una propiedad y se
intenta recompilar, se produce un error en "OtraClase" porque la llamada a
Funcion1 ya no acepta el "ref c.campo". Con lo cual lo único que pretendía
decir es que no son 100% intercambiables los campos con las propiedades,
porque puede afectar al código (externo a la clase) que hace uso de dichos
campos. Esto afecta al responsable de mantener "MiClase", que no puede
alegremente sustituir los campos por propiedades pensando que no van a
afectar a los programas que usen dicha clase, porque podría ser que alguno
(como en el ejemplo de "OtraClase") sí que se viera afectado. Lo cual no
significa necesariamente que sea una buena idea hacer "de entrada" un diseño
como ese.

Responder a este mensaje

#17 RFOG

22/05/2007 - 09:57 | Informe spam

En Tue, 22 May 2007 09:47:03 +0200, Alberto Poblacion
escribió:

"RFOG" wrote in message
news:

A mayor abundamiento, hay otro caso más en que tampoco son
compatibles los campos con las propiedades: Un campo se puede pasar
como argumento tipo "ref" a una función. Si sustituyes el campo por
una propiedad, deja de ser compatible a nivel de código fuente porque
la propiedad no puede pasarse de esa manera.

Yap, pero el único propósito de pasar una variable miembro a una
función es la de pasársela a un método de otra clase (porque desde tu
propia clase deberías acceder directamente a la variable miembro)... lo
que viola todos los paradigmas de la orientación a objetos.

No entiendo nada. ¿Qué tiene eso que ver con lo que yo digo?:

class MiClase
{
public string campo;
}
...
class OtraClase
{
void Funcion1(ref string x)
{...}
void HacerAlgo()
{
MiClase c = new MiClase();
Funcion1(ref c.campo);
}
}

}
...
class OtraClase
{
void Funcion1(ref string x)
{...}
void HacerAlgo()
{
MiClase c = new MiClase();
String s=c.campo;
Funcion1(ref s);
}
}

Ahora ya da igual que campo sea una propiedad o una variable. Estás
gastando un puntero s más, pero si el optimizador es bueno, se lo saltará
y meterá directamente en la pila el valor de retorno de c.campo para que
lo use Funcion1.

Aquí vemos que si en "Miclase" se cambia "campo" por una propiedad y
se intenta recompilar, se produce un error en "OtraClase" porque la
llamada a Funcion1 ya no acepta el "ref c.campo". Con lo cual lo único
que pretendía decir es que no son 100% intercambiables los campos con
las propiedades, porque puede afectar al código (externo a la clase) que
hace uso de dichos campos. Esto afecta al responsable de mantener
"MiClase", que no puede alegremente sustituir los campos por propiedades
pensando que no van a afectar a los programas que usen dicha clase,
porque podría ser que alguno (como en el ejemplo de "OtraClase") sí que
se viera afectado. Lo cual no significa necesariamente que sea una buena
idea hacer "de entrada" un diseño como ese.

A eso me refiero: como no es buena idea, no tiene mucho sentido, aparte de
que rompe los paradigmas de la OO.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
El que dé rosas de comer al burro, cobrará con un rebuzno.

Responder a este mensaje

#18 Alfredo Novoa

22/05/2007 - 10:27 | Informe spam

Hola Alberto,

On Tue, 22 May 2007 08:33:59 +0200, "Alberto Poblacion"
wrote:

A mayor abundamiento, hay otro caso más en que tampoco son compatibles
los campos con las propiedades: Un campo se puede pasar como argumento tipo
"ref" a una función. Si sustituyes el campo por una propiedad, deja de ser
compatible a nivel de código fuente porque la propiedad no puede pasarse de
esa manera.

Otro fallo más para la lista.

Saludos

Responder a este mensaje

#19 Alfredo Novoa

22/05/2007 - 10:38 | Informe spam

On Tue, 22 May 2007 09:08:02 +0200, RFOG
wrote:

No quiero entrar en polémicas, pero... hasta donde yo sé ningún lenguaje
ni framework deja hacer eso...

Pues puede ser, tendré que mirar, pero no deja de ser un fallo. Pero
hay muchos lenguajes que no tienen forma binaria.

El que se deban de usar propiedades que no hacen nada en lugar de
variables no es por ningún principio de programación, sino por
peculiaridades internas de algunas plataformas.

Es como si un programa petase si cambiamos una tabla por una vista con
la misma estructura. Sería un fallo grave de la plataforma.