Propiedades autoimplementadas

Yo entiendo tanto lo que dice Ricardo como Alfredo y concluyo de lo que tu
dices que si no debiera usarse nunca un campo público, para qué existen
entonces los campos públicos.. no deberian existir.
Aparte decir que en el ejemplo que di estoy expresando que la propiedad es
autoimplementada, o sea sin codigo de acceso. Bajo ese supuesto la mera
verdad que no me convence ninguna de las ventajas que han citado ustedes.

Pero les agradezco sus explicaciones.

2"Octavio Hernandez" escribió en el mensaje
news:

Hola, Ricardo!

Mira la respuesta de Alfredo más abajo, creo que esa es la ventaja
principal.
Yo pienso que un campo público no se debe usar NUNCA-NUNCA.

Salu2 - Octavio



"Ricardo Passians" wrote in message
news:

Para este ejemplo específico que das (propiedad sin código accesor), a
menos que necesites ver tu propiedad en tiempo de diseño en la ventana de
propiedades, pienso que puede preferirse usar un campo público ya que la
propiedad no te daría prácticamente ningún valor agregado.

Ricardo Passians


"Pedro" <pd> escribió en el mensaje
news:

Gracias por la explicacion pero yo me refiero a las "propiedades
autoimplementadas" o "auto-implemented properties" del VS2008, o sea
esas que se definen sin tener un campo privado asociado de la manera:

public bool prop {get; set; }

como ves, no tiene ningun codigo.

La pregunta es si para este caso es lo mismo que definir un campo:

public bool prop;

ya que segun veo de todas maneras no existe (o no se puede acceder a)
ningun campo privado asociado a dicha propiedad.




"Paulino Padial López" escribió en el mensaje
news:eI%23m$

Umm no lo entiendo muy bien, pero primero hay que diferenciar lo que es
una propiedad, y lo que es un campo...

La funcion de definir propiedades a un campo es precisamente, porque
queremos proteget el campo, o moldear su acceso o salida de la clase.
Por ejemplo:
imagina que tenemos
class persona
private string _codigo;

Queremos que solo podamos obtener el codigo pero no podamos
modificarlo, si ponemos codigo como public, haciendo
objeto.codigo = newcodigo
lo podemos modificar.
Si le creamos una propiedad podemos limitar esto, porque para acceder
a la variable tendremos que usar una propiedad, en este caso creamos la
propiedad GET pero no SET de este modo el acceso a la variable sería
solo por GET que es obtener.

Las propiedades antes eran las tipicas funciones que creabamos
setCodigo() getCodigo() pero mas "bonitas" y nos sirven para darle un
flujo de entrada o salida a las variable de nuestra clase,
manteniendolas seguras.

No se si esto responderá tu duda

saludos cordiales,


"Pedro" <pd> escribió en el mensaje de noticias
news:%

que diferencia hay entre usar una propiedad autoimplementada sin
codigo:

public bool pk {get; set; }

o usar un campo publico:

public bool pk;
?


VS2008

Hola Pedro,

On Tue, 22 Apr 2008 20:39:06 -0400, "Pedro" <pd> wrote:

Yo entiendo tanto lo que dice Ricardo como Alfredo y concluyo de lo que tu
dices que si no debiera usarse nunca un campo público, para qué existen
entonces los campos públicos.. no deberian existir.

Tienes razón. Con la incorporacón al lenguaje de las propiedades
autoimplementadas los campos públicos ya no deberían existir. Lo que
pasa es que se mantienen por razones de compatibilidad hacia atrás. Es
decir para que puedan seguir compilandose las aplicaciones antiguas.
Pero es una cosa que no se debería de usar en aplicaciones nuevas.


Saludos
Alfredo

"Pedro" <pd> escribió en el mensaje
news:

Yo entiendo tanto lo que dice Ricardo como Alfredo y concluyo de lo que tu
dices que si no debiera usarse nunca un campo público, para qué existen
entonces los campos públicos.. no deberian existir.
Aparte decir que en el ejemplo que di estoy expresando que la propiedad es
autoimplementada, o sea sin codigo de acceso. Bajo ese supuesto la mera
verdad que no me convence ninguna de las ventajas que han citado ustedes.

Diferencia y ventaja no es lo mismo. Lo que ellos te dicen es previendo un
posible cambio de la interface pública en el futuro, y eso ciertamente
tiene mucho sentido. También aplica si en alguna clase heredada quieres
hacer un "override" de esta propiedad para meterle código aunque no lo
tuviere en su clase base y no quieres o no puedes recompilar el assembly.
Pero si la propiedad nunca tendrá código (por diseño), lo cual también es
posible en determinados casos, el campo público es funcionalmente lo mismo y
hasta más eficiente su acceso.

Saludos

Ricardo Passians

Hola Ricardo,

On Wed, 23 Apr 2008 07:34:26 -0400, "Ricardo Passians"
wrote:

Pero si la propiedad nunca tendrá código (por diseño), lo cual también es
posible en determinados casos, el campo público es funcionalmente lo mismo y
hasta más eficiente su acceso.

Eso depende de la calidad del compilador JIT.

Sería perfectamente posible que las dos opciones tuviesen el mismo
rendimiento.


Saludos
Alfredo

On Wed, 23 Apr 2008 13:41:40 +0200, Alfredo Novoa
wrote:

Sería perfectamente posible que las dos opciones tuviesen el mismo
rendimiento.

Aunque también sería perfectamente posible hacer que las aplicaciones
no cascasen al sustituir un campo por una propiedad.


Saludos
Alfredo