2010-10-22 17 views
14

Aparte de un punto de vista arquitectónico, me pregunto si hay alguna diferencia en .net entre una propiedad de solo lectura y una función. ¿Las propiedades son solo envoltorios conceptuales de las funciones?¿Cuál es la diferencia entre la propiedad de solo lectura y la función en .net?

Private m_Property As String 
    Public ReadOnly Property PropertyGet() As String 
     Get 
      Return m_Property 
     End Get 
    End Property 

    Public Function FunctionGet() As String 
     Return m_Property 
    End Function 

Desmontaje IL muestra que no hay diferencia aparte del nombre, pero hay diferencias en otro nivel? ¿Es el getter solo una función en la mano corta (!?)?


Edit: Wow, me siento mucho por no ser capaz de marcar varias respuestas.

La primera respuesta que señalaba el uso de propiedades para serializar era el camino hacia la iluminación, ya que había dejado completamente este aspecto. Antes de eso, la explicación de propiedad vs función como "es" vs "hace" se sintió arbitraria. Ahora, lo grok más.

Creo que el consenso sobre la propiedad que no consume mucho tiempo se deriva del concepto "es"/serializable . Si mi propiedad habla con una base de datos para almacenar el valor "es", se rompe de maneras horribles.

+0

+1. Esto solía molestarme en mis primeros días de VB.NET. Afortunadamente lo he superado ahora. –

Respuesta

5

Una propiedad combina ambos conceptos de campos y métodos. De hecho, una propiedad se accede como un campo, pero los fragmentos de código subyacentes son métodos. La parte de campo de una propiedad le permite acceder a un valor como lo haría un campo, aunque le permite engañar a esta función captadora y al procedimiento setter, si se me permite. Las propiedades se usan más comúnmente para controlar un valor de campo asignado o devuelto. Y bajo el riesgo de repetirme, se accede a ellos como un campo.

Por otro lado, las funciones, procedimientos, ambos conocidos como métodos en OOP, son, por definición, rutinas para procesar la información. Debe haber un proceso sobre un objeto o información, por ejemplo, no es raro encontrar el nombre de una función como DoThis, DoThat ... Se pueden usar sobre campos o propiedades, pero se sabe que las funciones afectan más de solo un campo, o controlar un valor sobre un campo. Las funciones, por oposición a las propiedades, pueden tener múltiples parámetros, parámetros opcionales e incluso ser genéricos.

Me gustaría agregar que, que yo sepa, una propiedad no puede ser anónima, ni genérica. Atención, no digo que una propiedad no pueda devolver un genérico, digo que la propiedad en sí no puede ser genérica. Una función puede ser anonymous y generic.

En resumen, una propiedad es un concepto usado sobre un campo, para obtener control sobre un valor de campo, mientras que las funciones son ejecutadoras, esperamos que realicen tareas, y no solo asignaciones.

2

sí, la propiedad es solo un concepto de alto nivel sobre los métodos Establecer/Obtener.

13

La diferencia es más semántica que funcional; un captador de propiedades es, de hecho, una función bajo el capó. La diferencia es más que como programador, a menudo se espera que llamar a un comprador de propiedades sea una operación muy barata, mientras que llamar a una función podría ser potencialmente más costoso.

Tenga en cuenta que este no es necesariamente el caso; puedes implementar muy bien funciones muy livianas, y captadores de propiedades muy pesados, pero como regla general, un comprador de propiedades típicamente no debe hacer mucho más que simplemente obtener el valor.

+1

Para mí es más que eso: es una relación de datos versus acción. Su objeto puede * realizar * una llamada a la base de datos, pero los datos en la base de datos no son propiedad del objeto. Por ejemplo, su aplicación podría construir una matriz de objetos 'cliente' de la base de datos, y estos representarían el modelo real de los datos, por lo que sus propiedades serían las suyas, y entre otras características, este' cliente 'sería serializable, mientras que la 'base de datos' no. Además, las propiedades ** nunca ** deben causar excepciones, y el acceso a los datos, la interoperabilidad nativa, etc. no son seguros.Solo mis 2 centavos. –

2

Una propiedad es la misma que una función. Pero una propiedad indica que está obteniendo (o estableciendo) "propiedades" (Variables miembro) de un objeto y que estos getter/setter son no función que consume mucho tiempo que, por ejemplo, calcula algo o consulta la base de datos. Por lo tanto, son un azúcar sintáctico útil (si se implementan correctamente).

1

La propiedad get/set es syntatcit sugar. Readonly en VB es solo una manera de especificar que solo desea obtener la 'función'

Puede parecer que debe pasar propiedades por referencia (ByRef) a los métodos, pero como usted señala es una función no real tipo.

Tiendo a utilizar funciones para getters cuando la operación es costosa, p. GetCustomersFromDatabase()

8

Hay una diferencia importante si utiliza el enlace de datos, simplemente no puede enlazar a un método, solo puede enlazar a las propiedades.

3

Todo el asunto de la propiedad fue, probablemente, concebido para evitar obtener un montón de métodos separados GetSomething(), SetSomething (var x), que solían ser la norma en, por ejemplo, Java a principios de 2000 para el acceso a datos . Esto para evitar variables públicamente expuestas.

Créanme, esas clases parecían horribles. Personalmente, creo que el concepto de propiedad es un gran avance en la legibilidad y la estructura.

+0

+1 me parecieron raros y algunos insisten en escribir UML así, me parece menos legible ver muchos 'GetSomething' y' SetSomething'. –

2

obtener propiedades se espera que sean puras, y si nos fijamos en los contratos de código .net, verá que suponen que los getters son puros. Por lo tanto, llamar a una propiedad para obtener una, dos o 10 veces no debería tener ninguna diferencia con el objeto, donde como llamar a un método en un objeto, puede conducir a múltiples cambios en el estado de los objetos.

+1

... Porque las propiedades * son * el estado. –

0

la palabra clave readonly simplemente significa "Estimado compilador no esperes un setter" "y si lo hago, castímeme". Esta es una decisión de sintaxis de VB. Las funciones detrás de escena y los captadores de propiedades son iguales.

0

La ventana normal de depuración de una clase mostrará los valores de las propiedades no indexadas, pero no mostrará los resultados de las funciones. Una de mis preocupaciones con la clase StringBuilder es que no tiene una propiedad para el contenido actual de la cadena, lo que hace que la ventana del reloj sea mucho menos útil de lo que sería de otra manera.

Además, las propiedades no indexadas, a diferencia de los métodos, no requieren un() después del nombre; Creo que las propiedades indexadas en C# son necesarias para usar [] en lugar de() para sus parámetros.

+0

Todos los índices en C# son como 'índice [0]' AFAIK. –

1

Me gustaría agregar, como una estafa para el uso de propiedades, que la serialización entiende el concepto de propiedades y las utiliza, mientras que no sabe nada acerca de los métodos getter/setter. Además, si está utilizando una propiedad en un estilo compacto como:

public int MyProperty { get; private set; } 

se puede prescindir de un buen montón de líneas de código a partir de los archivos de origen, haciéndolos más fácil de leer.

Cuestiones relacionadas