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;

}

}

Preguntas similare

Leer las respuestas

#21 RFOG
22/05/2007 - 11:06 | Informe spam
Alfredo Novoa a utilisé son clavier pour écrire :
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.



No sé, quizás estemos confundiendo frameworks y bibliotecas con
lenguajes...

Además, Sutter (uno de los creadores del
C++/CLI y puntales del C++) recomienda el uso de las propiedades frente a
las variables.



Será por los fallos en la intercambiabilidad :-)



grrrrrrrr. :-)

Saludos





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
Respuesta Responder a este mensaje
#22 RFOG
22/05/2007 - 11:11 | Informe spam
Alfredo Novoa a présenté l'énoncé suivant :
On Tue, 22 May 2007 09:57:18 +0200, RFOG
wrote:

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



La OO ya nació haciendo agua por todas partes, pero usas la palabra
paradigma de una forma bastante extraña.

Paradigma significa ejemplo.



Pues díselo al traductor de Stroustrup y de Bertrand Meyer...

El drae trae otras acepciones:

1. m. Ejemplo o ejemplar.

2. m. Ling. Cada uno de los esquemas formales en que se organizan las
palabras nominales y verbales para sus respectivas flexiones.

3. m. Ling. Conjunto cuyos elementos pueden aparecer alternativamente
en algún contexto especificado; p. ej., niño, hombre, perro, pueden
figurar en El -- se queja.

Supongo que la 3, y el traductor de inglés que tengo traduce paradigma
por modelo, y la inglesa paradigm devuelve: paradigma, arquetipo,
estándar, paterna, prototipo para el castellano y model, ideal; mold,
form; example, pattern como sinónimos.

Creo que está clara mi acepción: filosofía o modelos o ideales OO. :-)

Saludos





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
Respuesta Responder a este mensaje
#23 RFOG
22/05/2007 - 11:11 | Informe spam
Alfredo Novoa a exprimé avec précision :
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.



xdddddddddddddddddddddddddddddddd

Saludos





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
Respuesta Responder a este mensaje
#24 Juan Carlos Paramá
22/05/2007 - 12:28 | Informe spam
Hola,

"Alfredo Novoa" escribió en el mensaje de
noticias news:
On Tue, 22 May 2007 09:08:02 +0200, RFOG

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.




¿Las propiedades no hacen nada?


class A {

public int edad;

public int Edad {
get { return edad; }
set {
if(edad<18) {
throw new Exception("No admitimos clientes menores de edad.");
}
edad = value;
}

}

class b {

void ...() {

A var = new A();
var.edad = -25; // mal, permite a no nacidos ser clientes (se
puede solucionar con uint)
var.edad = 13; // mal, permite a menores de edad ser
clientes (no se puede solucionar excepto externamente)
var.Edad = 13; // correcto, no permite clientes menores de
edad sea quien sea que intente asignar la edad sin comprobaciones externas

}

}

Yo diría que la propiedad si hace "algo" que no se puede hacer con una
variable.



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.



TABLA(int id, int valor1, int valor2)
TABLA2(int id, int valor3, int valor4)

VISTA(int, int, int)

Tanto TABLA, TABLA2 como VISTA tienen la misma estructura
y sin embargo no siempre se puede cambiar TABLA por VISTA. Por ejemplo
si la vista es:

SELECT id, valor1, valor2 FROM TABLA
UNION
SELECT id, valor3, valor3 FROM TABLA2

Saludos,

Juan Carlos Paramá
Respuesta Responder a este mensaje
#25 Juan Diego Bueno
22/05/2007 - 12:59 | Informe spam
Sin profundizar, ya que mis conocimientos en OO son bastante
limitaditos... hace tiempo leí en un artículo de una revista sobre
mejoras en el rendimiento de las aplicaciones .NET que era preferible
usar variables públicas allí donde no hiciera falta una validación del
valor recibido (a nivel de rendimiento, ojo). No se si alguien tendrá
esto por ahí documentado, pero me quedé con la copla.

Saludos

On 22 mayo, 12:28, Juan Carlos Paramá
wrote:
Hola,

"Alfredo Novoa" escribió en el mensaje de
noticiasnews:

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

> 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.

¿Las propiedades no hacen nada?

class A {

public int edad;

public int Edad {
get { return edad; }
set {
if(edad<18) {
throw new Exception("No admitimos clientes menores de edad.");
}
edad = value;
}

}

class b {

void ...() {

A var = new A();
var.edad = -25; // mal, permite a no nacidos ser clientes (se
puede solucionar con uint)
var.edad = 13; // mal, permite a menores de edad ser
clientes (no se puede solucionar excepto externamente)
var.Edad = 13; // correcto, no permite clientes menores de
edad sea quien sea que intente asignar la edad sin comprobaciones externas

}

}

Yo diría que la propiedad si hace "algo" que no se puede hacer con una
variable.



> 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.

TABLA(int id, int valor1, int valor2)
TABLA2(int id, int valor3, int valor4)

VISTA(int, int, int)

Tanto TABLA, TABLA2 como VISTA tienen la misma estructura
y sin embargo no siempre se puede cambiar TABLA por VISTA. Por ejemplo
si la vista es:

SELECT id, valor1, valor2 FROM TABLA
UNION
SELECT id, valor3, valor3 FROM TABLA2

Saludos,

Juan Carlos Paramá
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida