problema con HERENCIA

Fue que el ejemplo de una edad límite mas bien me pareció a una regla de
integridad o una restricción check de una base de datos.
Pero si no es en un sistema de base de datos, bueno, ok.

Saludos

Jose TH

Ya te ha respondido Alfredo Novoa. Yo no hago nada que tenga que ver con
bases de datos, y uso las propiedades casi a espuertas.


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.

"RFOG" wrote in message
news:

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.

Si, ¿pero y si el "OtraClase" no es tuyo? Es decir, a tí te encargan
mantener "MiClase", y esta clase está en una librería que muchos
programadores que tú no conoces han utilizado. Cuando te encuentras que
MiClase tiene un campo público, observas que no te gusta ese diseño y
decides que procede corregirlo y cambiarlo por una propiedad. Piensas que
puedes cambiarlo alegremente porque no va a afectar a ninguno de los
programas existentes (que no conoces ni puedes cambiar) que llaman a esa
librería. Y resulta que no, que no puedes hacer ese cambio porque sí puede
haber algunos programas que se rompan con ello (y que desde luego podrían
corregirse si hubiera alguien encargado de hacerlo, cosa que está fuera de
tu control).

La conclusión, volviendo a conectar con el origen de este hilo de
discusión, es que el diseño inicial de la clase no debería contener un campo
público sino una propiedad, aunque la propiedad por ahora no haga nada de
nada, porque en caso contrario se dificulta el posterior mantenimiento del
código en el caso de que en el futuro se necesite que sí que haya una
propiedad para meter algo de código en el acceso al campo.

En Tue, 22 May 2007 21:37:47 +0200, Alberto Poblacion
escribió:

"RFOG" wrote in message
news:

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.

Si, ¿pero y si el "OtraClase" no es tuyo? Es decir, a tí te encargan
mantener "MiClase", y esta clase está en una librería que muchos
programadores que tú no conoces han utilizado. Cuando te encuentras que
MiClase tiene un campo público, observas que no te gusta ese diseño y
decides que procede corregirlo y cambiarlo por una propiedad. Piensas
que puedes cambiarlo alegremente porque no va a afectar a ninguno de los
programas existentes (que no conoces ni puedes cambiar) que llaman a esa
librería. Y resulta que no, que no puedes hacer ese cambio porque sí
puede haber algunos programas que se rompan con ello (y que desde luego
podrían corregirse si hubiera alguien encargado de hacerlo, cosa que
está fuera de tu control).

La conclusión, volviendo a conectar con el origen de este hilo de
discusión, es que el diseño inicial de la clase no debería contener un
campo público sino una propiedad, aunque la propiedad por ahora no haga
nada de nada, porque en caso contrario se dificulta el posterior
mantenimiento del código en el caso de que en el futuro se necesite que
sí que haya una propiedad para meter algo de código en el acceso al
campo.

Puñetas, si es lo que estoy diciendo, que pese a que no se pueda pasar una
propiedad como parámetro es preferible usarlas...


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.

Hola,


"Alfredo Novoa" escribió en el mensaje de
noticias news:

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.

Excepto facilitar el mantenimiento de un aplicación.

Acepto que en casos extremos, donde el rendimiento sea el objetivo básico,
una
variable pública puede ser razonable. En el resto de casos no le veo mucho
sentido
al utilizar variables públicas en vez de propiedades ni siquiera para
propiedades "Internal".

Las ventajas de mantenimiento compensan la minima caida de rendimiento.

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.

No todos los motores permiten unions actualizables, en los que los permiten
hay soluciones tan poco elegantes como insertar el mismo registro en todas
las
tablas de la unión y eso no siempre es posible si por ejemplo una de las
selects
tiene una función o campo calculado, etc.

Es decir, igual que con las propiedades las vistas no son intercambiables
por las
tablas. Los son en algunas circunstancias y no en otras. Eso no es un
defecto de
diseño. Son cosas distintas aunque en ocasiones se comporten igual.

Saludos,

Juan Carlos Paramá

En Tue, 22 May 2007 13:22:07 +0200, Alfredo Novoa
escribió:

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" }:-)

¿Cómo lo traducirías tu? Es que no veo otra palabra para ello.

Desde luego que como a su significado original clama al cielo (eso o poner
una póliza de 5 ptas a cada "ejemplo" en tiempo de ejecución de la clase
susodicha, y luego llevarla a la ventanilla 6). :-P
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.