¿Cuál es mejor utilizar cuando se trata de devolver el valor, por ejemplo,Diferencia entre la propiedad y método
public int EmployeeAge
{
get{return intEmployeeAge};
}
Y
public int EmployeeAge()
{
return intEmployeeAge;
}
cuál es mejor y por qué? ¿Y cuál es la mejor práctica de programación para usar cuando tenemos un secnario como el anterior?
Las propiedades son una forma útil de expresar una característica de un objeto, permitiendo obtener/establecer de una manera común que puede ser utilizada por las API como el enlace de datos, la reflexión y la serialización. Por lo tanto, para los valores simples del objeto, las propiedades son útiles. Las propiedades no pueden tomar argumentos, no deben tener efectos secundarios significativos *, y deben regresar de forma rápida y repetible. Además, no existe una "propiedad de extensión" (para reflejar un método de extensión) ni una propiedad genérica.
(* = perezoso de carga, etc. No es raro, sin embargo)
Métodos (C# no tiene funciones) son mejores para expresar las cosas que, o bien el cambio el estado, o que tienen una expectativa de tomar un tiempo y no necesariamente reproducible. No tienden a trabajar en vinculante/serialización, etc.
Tenga en cuenta que las propiedades son en realidad una forma especial de escribir métodos. Hay poca diferencia funcional. Se trata de expresar intención. Lo único que no quiere querer exponer, sin embargo, es campos (la variable de instancia real intEmployeeAge).
por lo que tendría:
public int EmployeeAge { get{return intEmployeeAge}; }
o simplemente (si en el objeto Employee):
public int Age { get{return intEmployeeAge}; }
Por supuesto ... entonces la pregunta es: "¿En qué unidad?" Supongo que son años?
Un método devuelve valores una vez que se ha completado el trabajo y un valor es el resultado del trabajo realizado. No creo que esto sea lo que estás haciendo.
Una propiedad (de acceso) está destinado para las variables que regresan, lo que parece ser lo que usted está tratando de lograr:
Según MSDN:
El descriptor de acceso de una propiedad contiene el ejecutable declaraciones asociadas con obtener (leer o calcular) o establecer (escribir) la propiedad. Las declaraciones del descriptor de acceso pueden contener un descriptor de acceso , un descriptor de acceso de conjunto o ambos. Las declaraciones tomar las formas siguientes:
public int EmployeeAge
{
get;
set;
}
Tener un look here, ya que da una muy buena descripción sobre los usos de los mismos.
Creo que esto tiene mucho que ver con la cultura en la que está programando. Como yo lo veo, la cultura C#/.NET sería preferiría usar una propiedad para este caso.
Mi consejo: intente ser coherente con las bibliotecas principales que está utilizando.
PERO: Tenga cuidado con el uso de propiedades (o funciones que sirven para el mismo propósito, como en su ejemplo anterior), ya que a menudo son un signo de mal diseño. Desea decirle a sus objetos para hacer cosas, a diferencia de preguntando por información. Sin embargo, no seas religioso acerca de esto, solo sé consciente de esto como un olor a código.
Cultura? no entiendo su punto, ya que en ambos casos solo devuelve la edad del empleado. –
By * culture * Me refiero al cuerpo de código que viene con un idioma/plataforma, la comunidad de desarrolladores que los utilizan y las bibliotecas que crean. –
No entiendo su código de referencia de olor. Un objeto complicado puede tener muchas propiedades, especialmente si tiene antepasados múltiples ... –
Si todo lo que necesita hacer es devolver un valor, use una propiedad.
Si necesita hacer algo antes de devolver un valor, use una función.
Pero en el caso de la propiedad, también puedo agregar algo de procesamiento, como lo llama "hacer algo" antes de devolver el valor en la propiedad, en el caso anterior, ambos devuelven valor. pero, ¿cuál es mejor? –
Sí, puedes, pero debes pensar en _meaning_. La mayoría de los programadores, al llamar a una propiedad, no esperan que cambie el estado del objeto, pero cuando llaman a una función esperan esto. – Oded
Propiedades contiene los datos de objetos
Funciones define el comportamiento objeto
Tome un vistazo a ->Property Usage Guidelines
cuál es mejor y por qué? ¿Y cuál es la mejor práctica de programación para usar cuando tenemos secnario como el anterior?
escribo en C# sin embargo yo prefiero usar funciones get/set, para mí es sólo una mejor manera de expresar lo que puedo conseguir de objeto y cómo puedo cambiar su estado (y estos métodos están agrupados por orden alfabético en Intelisense, que también es agradable). Sin embargo, si el equipo prefiere otras convenciones, no es un problema, pero cuando trabajo en mis propios proyectos es más fácil leer la API.
e.g
Obejct1 o = new Object1();
o.P1;
o.P2;
o.P3;
de mirar con el API no se puede decir lo que cambia en una API pública o lo que una propiedad de sólo lectura, a menos que utilice IDE que muestra un pequeño icono que muestra realmente lo que puede hacer.
Object1 o = new Object1();
o.GetP1();
o.SetP2();
o.SetP3();
Uno puede encontrar fácilmente desde API cómo los datos pueden ser cambiados por los clientes del tipo.
La propiedad es una forma de explorar el elemento de datos internos de una clase de una manera simple. Podemos implementar las propiedades con el método de obtención y configuración type-safe. La propiedad se llama implícitamente mediante la convención de llamadas. Property funciona en compilación y en tiempo de ejecución.
El método es un bloque de código que contiene una serie de instrucciones. Se llama explícitamente método. Los métodos funcionan en tiempo de ejecución.
Llego un poco tarde a esta fiesta, pero mencionaré otra sorprendente diferencia entre una propiedad y un método "get" sin parámetros. Como señala @MarcGravell, la carga diferida es un patrón común cuando se usan propiedades, pero ten cuidado con el Heisenberg Watch Window gotcha!
buena respuesta .... –
/agreeed. De manera simple, las propiedades están diseñadas para exponer campos privados fuera de la clase para garantizar que no se produzcan cambios bruscos si se revisa la arquitectura de clase. – JoeBilly
@JoeBilly - bueno, puedes hacer un * bit * más que eso sin que se vuelva demasiado complicado. Pero lo simple es tan simple, dicen. –