Propiedades autoimplementadas

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

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

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

On Sun, 20 Apr 2008 09:47:12 -0400, "Pedro" <pd> wrote:

que diferencia hay entre usar una propiedad autoimplementada sin codigo:

public bool pk {get; set; }

o usar un campo publico:

public bool pk;
?

Pues creo que la diferencia está en el código que genera el
compilador.

Si usas un campo público en una DLL y luego lo conviertes a una
propiedad y no recompilas las aplicaciones, estas cascarán.

Si usas una propiedad autoimplementada sin código y luego le metes
código, pues las aplicaciones que usan la DLL no deberían cascar,
aunque no lo he probado.


Saludos
Alfredo

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