veo diferencia poco funcional entre el uso de una propiedad¿Por qué es mejor usar propiedades de solo lectura en lugar de funciones?
public readonly property foo as string
get
return bar
end get
end property
o una función
public function foo() as string
return bar
end function
Por qué iba a querer usar una forma sobre la otra?
Gracias!
Leí un artículo interesante recientemente en la Revista Visual Studio que discutía los diferentes métodos y propiedades.
Se supone que las propiedades devuelven un valor y el mismo valor cada vez, a menos que se invoque algo más.
Por lo general, se espera que un método haga algo en segundo plano para obtener el valor, o que el método pueda cambiar el valor cada vez que se lo llame, como GetNextId() o algo así.
DateTime.Now es un buen ejemplo de una propiedad que debería haber sido un método, ya que devuelve un valor diferente cada vez que se utiliza.
Para aquellos interested- Aquí está el artículo
Es puramente una cuestión de apariencia. Los métodos implican hacerlo así, mientras que las propiedades implican obtener algunos datos.
Desde esa perspectiva, podría argumentar que obtener propiedades debería implicar una const del objeto host. –
@DrFloyd: Cierto, de hecho lo hubiera dicho si hubiera pensado en una buena forma de expresarlo. –
Además de la semántica mencionada por James (declaración de intenciones), las propiedades desempeñan una función especial ya que el depurador muestra su valor y puede utilizarse en diseñadores visuales.
Como consecuencia, asegúrese de que los valores de las propiedades no cambien sin alguna acción externa, ya que de lo contrario, el depurador arruinará su programa.
Por lo que sé, todo se resume en lo mismo. Una propiedad en IL para .NET es realmente solo una función getPropertyName y setPropertyName para una propiedad llamada PropertyName.
Así que es realmente una cuestión de estilo en ese sentido. Simplemente lee mejor ver lo siguiente:
person.Address.Street;
en lugar de
person.Address().Street();
Así que, en cierto modo, es realmente una cuestión de estética de código.
Desafortunadamente para mí en .NET C#, no es tan elegante como Ruby en que () son siempre opcionales.
VB.Net no siempre requiere(), solo C# – Nescio
Bueno, compila * no * hasta la misma cosa, como usted mismo dijo. El compilador es muy consciente de las diferencias entre los dos y podría tratarlos de manera muy diferente. –
C# requiere() por una buena razón. Sin los paréntesis, significa algo completamente diferente. Ver: delegados. –
A mi entender, no se puede DataBind a métodos; solo propiedades Por lo tanto, las propiedades tienen ese beneficio adicional.
No se puede enlazar a los métodos porque se llama databind , no acción-vínculo. Propiedades IMO = datos, métodos = acciones. –
Si se basa en las Pautas de diseño del marco, debe utilizar un método solo cuando esté realizando una acción o accediendo a recursos que podrían ser caros de usar (base de datos, red).
La propiedad le da al usuario la impresión de que los valores se almacenan en la memoria y que leer una propiedad es rápido, mientras que llamar a un método podría tener implicaciones adicionales que simplemente "obtener el valor".
Brad Abrams en realidad escribió un article al respecto e incluso se publicó en MSDN here.
Le recomendaría encarecidamente que compre el libro Framework Design Guidelines. Es una lectura obligada para cada desarrollador.
Mi opinión es que si nos fijamos en las palabras - "propiedad" en comparación con "método". La palabra "propiedad" implica que "este es un valor inherente al objeto, como el color, tamaño, propietario ... llamar a una propiedad implicaría una operación relativamente simple para devolver ese valor. O, si no es de solo lectura, propiedad, configurar la propiedad también debe ser una operación relativamente simple (y de bajo costo)
Por otro lado, un "método" implica "Tengo que hacer un trabajo real para realizar esta tarea que me piden "- mientras que un método bien puede devolver un valor (aunque sea para decir" Sí, lo hice "), está haciendo un montón de cosas para obtener ese valor para mí, y al hacerlo, hará que otro operaciones asociadas con obtener ese valor.
Por lo tanto, es principalmente semántica - una propiedad de solo lectura podría implementarse satisfactoriamente como método - pero Me gustaría ver qué implica devolver ese valor, y las implicaciones que cada uno enviaría a la persona que recupera esa propiedad o llama a ese método.
Una razón para elegir una Propiedad ReadOnly sobre una función es que durante la depuración del tiempo de ejecución Los valores de la propiedad se pueden observar fácilmente. No puede obtener un resultado de función sin llamar a la función.
Vale la pena considerar si la operación es costosa y, si es así, elegir una función sobre una propiedad. Pero si no lo es, elegir propiedades hace que trabajar con un objeto durante una sesión de depuración sea un poco más fácil.
Esa es una diferencia de comportamiento interesante que se puede identificar usando la palabra clave const en algunos otros idiomas. Piensa como "se supone" y "debería" son lugares para esconder la religión. Una definición explícita permite estándares en lugar de convenciones. –
'DateTime.Now' es excelente como una propiedad. Aunque su valor cambia todo el tiempo, esto no tiene ninguna influencia (ya que 'DateTime's es inmutable y la propiedad se comparte!) Y además, no depende de la llamada (como un contador o un número aleatorio), pero en alguna otra variante fuera del programa –
Oye, no me votes por ello: busca al tipo que escribió el artículo. Además, una Propiedad no debería cambiarse a sí misma; si lo hace, ya no es una Propiedad ... es un Método – Hugoware