Cuándo utilizar propiedades en lugar de funciones

Question

Esta es probablemente una cuestión de preferencia personal, pero cuando usted utiliza las propiedades en lugar de funciones en el código

Por ejemplo para obtener un registro de errores que pudiera decir

string GetErrorLog() 
{ 
     return m_ErrorLog; 
} 

o podría

string ErrorLog 
{ 
    get { return m_ErrorLog; } 
} 

, ¿cómo decidir cuál utilizar? Parece ser inconsistente en mi uso y estoy buscando una buena regla general. Gracias.

Answer 1

que tienden a utilizar propiedades si lo siguiente es cierto:

• La propiedad devolverá un solo valor, la lógica
• Poca o ninguna lógica está implicado (por lo general acaba de devolver un valor, o hacer una pequeña comprobar el valor/retorno)

que tienden a utilizar métodos si se cumplen los siguientes:

Hay
• i va a ser un trabajo importante para devolver el valor, es decir: se obtendrá de un DB, o algo que puede tomar "tiempo"
• Hay bastante lógica involucrada, ya sea al obtener o establecer el valor

---

Además, me gustaría recomendar mirando Microsoft's Design Guidelines for Property Usage. Sugieren:

Utilice una propiedad cuando el miembro sea un miembro lógico de datos.

Uso un método cuando:

• La operación es una conversión, como Object.ToString.
• La operación es lo suficientemente costosa como para que desee comunicarle al usuario que debe considerar almacenar en caché el resultado.
• La obtención de un valor de propiedad con el acceso de get tendría un efecto secundario observable.
• Llamar al miembro dos veces seguidas produce resultados diferentes.
• El orden de ejecución es importante. Tenga en cuenta que las propiedades de un tipo se deben poder establecer y recuperar en cualquier orden.
• El miembro es estático pero devuelve un valor que se puede cambiar.
• El miembro devuelve una matriz. Las propiedades que devuelven matrices pueden ser muy engañosas. Por lo general, es necesario devolver una copia de la matriz interna para que el usuario no pueda cambiar el estado interno. Esto, junto con el hecho de que un usuario puede asumir fácilmente que es una propiedad indexada, conduce a un código ineficiente. En el siguiente ejemplo de código, cada llamada a la propiedad Methods crea una copia de la matriz. Como resultado, 2n + 1 copias de la matriz se crearán en el siguiente ciclo.

Answer 2

Estas son las directrices de Microsoft:

Choosing Between Properties and Methods

• considerar el uso de una propiedad si el miembro representa un atributo lógico del tipo.

• Utilice una propiedad, en lugar de un método, si el valor de la propiedad se almacena en la memoria de proceso y la propiedad solo proporcionará acceso al valor.

• Utilice un método, en lugar de una propiedad, en las siguientes situaciones.

  • La operación es mucho más lenta de lo que sería un conjunto de campos. Si incluso está considerando proporcionar una versión asíncrona de una operación para evitar el bloqueo del hilo, es muy probable que la operación sea demasiado costosa como para ser una propiedad. En particular, las operaciones que acceden a la red o al sistema de archivos (que no sea una vez para la inicialización) deberían ser métodos, no propiedades.

  • El funcionamiento es una conversión, como el método Object.ToString.

  • La operación devuelve un resultado diferente cada vez que se llama, incluso si los parámetros no cambian. Por ejemplo, el método NewGuid devuelve un valor diferente cada vez que se llama.

  • La operación tiene un efecto secundario significativo y observable. Tenga en cuenta que poblar un caché interno generalmente no se considera un efecto secundario observable.

  • La operación devuelve una copia de un estado interno (esto no incluye copias de los objetos de tipo de valor devueltos en la pila).

  • La operación devuelve una matriz.

Answer 3

nunca haría uso de una propiedad si pudiera estar afectando a más de un campo - Siempre haría uso de un método.

En general, solo uso la cadena pública ErrorLog {get; conjunto privado; } sintaxis para Propiedades y uso Métodos para todo lo demás.

Answer 4

Además de la respuesta de Reed cuando la propiedad solo va a ser un getter como obtener un recurso como podría ser un registro de eventos. Intento y solo uso propiedades cuando la propiedad estará libre de efectos secundarios.

Answer 5

Si hay algo más que algo trivial sucediendo en una propiedad, entonces debería ser un método. Por ejemplo, si su propiedad get del ErrorLog realmente estaba yendo y leyendo archivos, entonces debería ser un método. El acceso a una propiedad debe ser rápido, y si se está procesando mucho, debería ser un método. Si hay efectos secundarios de acceder a una propiedad que el usuario de la clase podría no esperar, entonces probablemente debería ser un método.

Hay .NET Framework Design Guidelines libro que cubre este tipo de cosas con gran detalle.

Answer 6

Utilizo propiedades cuando está claro que la semántica es "Obtener algún valor del objeto". Sin embargo, usar un método es una buena forma de comunicar "esto puede tomar un poco más que un esfuerzo trivial para regresar".

Por ejemplo, una colección podría tener una propiedad Count. Es razonable suponer que un objeto de colección sabe cuántos elementos se retienen actualmente sin que realmente tenga que recorrerlos y contarlos.

En la mano, esta colección hipotética podría tener el método GetSum() que devuelve el total del conjunto de elementos que contiene. La colección simplemente tiene fácilmente una propiedad Sum, pero al usar un método comunica la idea de que la colección tendrá que hacer un trabajo real para obtener una respuesta.