Últimos mensajes - Powered by IBM

Palabras claves

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

#26 Alfredo Novoa

22/05/2007 - 13:02 | Informe spam

On Tue, 22 May 2007 12:28:03 +0200, Juan Carlos Paramá
wrote:

¿Las propiedades no hacen nada?

Las propiedades de las que estamos hablando no hacen nada.

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

¿Y por que dices que no se pueden cambiar?

Si quieres puedes hacer esta vista actualizable.

Saludos

Responder a este mensaje

#27 Juan Diego Bueno

22/05/2007 - 13:04 | 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á

Responder a este mensaje

#28 RFOG

22/05/2007 - 13:14 | Informe spam

Es lógico que las propiedades sean más lentas porque hay que "ejecutarlas"
en lugar de simplemente obtener su valor.

Las propiedades son preferibles frente a las variables por una cuestión de
versiones futuras de tu programa, es decir, si creas una nueva versión de
una clase que exporta una variable púbilca, dichas versiones tendrán que
continuar exportando una variable si no quieren romper el código hacia
atrás, mientras que una propiedad te permite añadir código oculto.

Imagina, siguiendo el ejemplo de abajo, que ahora no haya límite de edad y
que luego lo impongan. Con una variable lo tienes crudo, con una propiedad
puedes hacer lo que el código de abajo.

En Tue, 22 May 2007 13:04:08 +0200, Juan Diego Bueno
escribió:

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á

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

#29 Alfredo Novoa

22/05/2007 - 13:22 | Informe spam

On Tue, 22 May 2007 11:11:07 +0200, RFOG
wrote:

Paradigma significa ejemplo.

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

El mundo de la traducción suele dejar bastante que desear. Hay muchas
traducciones que cambian completamente lo que quería decir el autor.

El otro día leí una crítica de una traducción que destrozaba un libro
con traducciones como: "casualidades de la guerra" por "casualties of
war", y otras burradas del mismo calibre.

Vamos, como traducir "instancia" por "instance" }:-)

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

Yo supongo que se refieren vágamente al sentido que le dió Kuhn en "La
Estructura de las Revoluciones Científicas".

http://es.wikipedia.org/wiki/La_est...C3%ADficas
http://es.wikipedia.org/wiki/Paradigma

, 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. :-)

Entonces sería en singular: el paradigma de la OO.

Saludos

Responder a este mensaje

#30 Alfredo Novoa

22/05/2007 - 13:25 | Informe spam

On Tue, 22 May 2007 11:11:28 +0200, RFOG
wrote:

Otro fallo más para la lista.

xdddddddddddddddddddddddddddddddd

No le veo la gracia. Esto viola claramente el principio de la
ortogonalidad, que si que es un principio sólido, no como los de la
OO.

La verdad es que la lista es bastante larga.

Saludos

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7 8

Busqueda sugerida