Propiedad vs Función (específicamente .NET)

Question

He leído algunas discusiones sobre este tema, y ​​hay algo que simplemente no entiendo.

La respuesta más común parece ser esta: utilizar una propiedad ReadOnly para devolver datos en caché, usar una función para devolver datos no almacenados en caché. No use ninguna propiedad WriteOnly en absoluto, ya que "no tiene sentido".

No hay ningún motivo de rendimiento para esto. En IL, MyProperty existe como get_MyProperty y set_MyProperty métodos. La única razón aparentemente es que se debe suponer la respuesta anterior.

Bien, entonces ¿para qué molestarse con las propiedades de ReadOnly en absoluto? ¿Por qué no simplemente hacer que la variable sea pública en lugar de privada? Entonces, ¿por qué molestarse con Propiedades en absoluto? Datos almacenados en caché -> Variable pública, datos no almacenados en caché -> Función, escritura de datos -> Sub

Olvidemos todo lo anterior, y use Propiedades como una característica útil? Un 'elemento' para obtener y establecer datos. Use el sentido común para saber si un Get no devolverá los datos en caché (lo que posiblemente resulte en un retraso).

-Edit- Veo personas más o menos de acuerdo en que las propiedades son la mejor opción. Simplemente no podía entender por qué encontré tantas discusiones en las que la gente abogó por las Propiedades.

Answer 1

Una buena razón para las propiedades de solo lectura son los valores que se calculan. En este caso, no hay variables para exportar.

Por ejemplo

public class Person { 
    private readonly DateTime _birthday; 
    public int Age { get { return (DateTime.Now - _birthday).TotalYears; } } 
    ... 
} 

En este caso si se debe exponer _Birthday como una propiedad o un campo es ciertamente discutible. Pero para otros valores calculados como Edad, la única forma de exponerlos como una variable es almacenarlos en el objeto. En este caso, tener una variable adicional para Age es esencialmente almacenar información redundante. Exponerlo como una propiedad calculada tiene una sobrecarga menor y evita almacenar datos redundantes

Answer 2

Las propiedades tienen propiedades adicionales a las propiedades automáticas. Si lo hace:

public int MyProp { public get; public set; } 

Entonces es realmente diferente de

public int MyProp; 

Pero la gran ventaja de la primera es que posteriormente se pueden cambiar a:

public int MyProp { 
    get { 
     // Do some processing 
     return someValue; 
    } 

    set { 
     // Do some processing 
     DoMyProcess(value); 
    } 
} 

y otros códigos que usa tu objeto funcionaría sin recompilar. Si, en cambio, hubiera usado un campo público, el código del cliente necesitaría ser recompilado si alguna vez desea cambiarlo de un campo a una propiedad.

Answer 3

Las propiedades son un sustituto conveniente para las operaciones basadas en métodos. No existe una diferencia funcional entre un conjunto de propiedades y un método que realiza las mismas acciones; de hecho, si nos fijamos en IL verás que los accesos a las propiedades son reemplazados por los métodos "get" y/o "set".

La razón más fuerte para usar propiedades que simplemente permitir el acceso a las variables es la encapsulación. Digamos que estás escribiendo una biblioteca y expones una variable IsBlue. Distribuyes la biblioteca, todos aman y la usan.Ahora es la hora de la versión 2 y desea hacer algo cuando el usuario configure IsBlue, tal vez realice una comprobación, tal vez haga una caché. Para hacer eso, tendrá que convertir la variable en una propiedad o método, y hacer la verificación allí. Ahora, has roto todo tu código de cliente: la variable a la que accedieron ya no está allí. Si lo había implementado originalmente como una propiedad, podría haber modificado el código de la propiedad y retenido la compatibilidad binaria.

Answer 4

"Datos en caché -> Variable pública" - mala idea. Esto permitiría que otra clase modifique los datos en caché. Además, calcular los datos para el almacenamiento en caché puede ser costoso: el uso de una propiedad de solo lectura le permite diferir el cálculo hasta que se acceda a la propiedad.

Answer 5

Se considera una mala práctica exponer su variable de su clase. Además, si cambia la estructura de su objeto pero mantiene sus propiedades intactas, no afectará el código que usa su clase.

Answer 6

Motivo n. ° 1 = Las propiedades se pueden utilizar en el enlace de datos. Los métodos no pueden.

Motivo # 2 = Al depurar la ventana del reloj expondrá automáticamente las propiedades/expandirá el objeto. Los métodos no se ven automáticamente de esta manera.

Recuerdo haber leído en algún lugar que la propiedad de lectura no debería cambiar el estado del objeto. Creo que es una buena práctica seguir especialmente teniendo en cuenta la razón # 2. Tan pronto como vea un objeto y lo expanda en el reloj, el estado de los objetos podría cambiarse, lo que dificultaría la depuración.

Además, si una propiedad costosa está limitada por accidente, puede presentar serios problemas de rendimiento. (Los atributos pueden "ocultar" las propiedades del enlace de datos, pero el simple hecho de que sean métodos significa que no tiene que preocuparse por ello).

Las propiedades son convenientes para el desarrollo de ventanas. Ellos son "utilizados" de manera diferente en los diseñadores etc.

(a veces simplemente expongo algunas variables Pero les nombre como lo haría una propiedad que en lugar de

Entero mCounter = 0;..

acabo hacer

Entero Contador = 0 ;.

Si tengo que hacer "cosas extra" en algún momento en el futuro crear la propiedad con el mismo nombre y cambiar el nombre de la variable a mCounter. es cierto que esta es la pereza de mi parte y yo realmente no re véndalo. Solo envuélvalo en una propiedad.)