Propiedades vs Métodos

Question

Pregunta rápida: ¿Cuándo decide utilizar las propiedades (en C#) y cuándo decide utilizar los métodos?

Estamos ocupados teniendo este debate y hemos encontrado algunas áreas donde es discutible si debemos usar una propiedad o un método. Un ejemplo es la siguiente:

public void SetLabel(string text) 
{ 
    Label.Text = text; 
} 

En el ejemplo, Label es un control en una página ASPX. ¿Hay algún principio que pueda regir la decisión (en este caso) si se trata de un método o una propiedad?

Voy a aceptar la respuesta que es más general y completa, pero que también se refiere al ejemplo que he dado.

Answer 1

Desde la sección Choosing Between Properties and Methods de Directrices de diseño para el desarrollo de bibliotecas de clases:

En general, los métodos representan acciones y propiedades representan datos. Las propiedades están destinadas a ser usadas como campos, lo que significa que las propiedades no deben ser computacionalmente complejas o producir efectos secundarios. Cuando no infringe las siguientes pautas, considere usar una propiedad, en lugar de un método, porque los desarrolladores menos experimentados encuentran las propiedades más fáciles de usar.

Answer 2

Sí, si todo lo que hace es obtener y configurar, use una propiedad.

Si está haciendo algo complejo que puede afectar a varios miembros de datos, un método es más apropiado. O si su getter toma parámetros o su setter toma más que un parámetro de valor.

En el medio es un área gris donde la línea puede ser un poco borrosa. No existe una regla dura y rápida, y diferentes personas a veces no estarán de acuerdo en si algo debe ser una propiedad o un método. Lo importante es ser (relativamente) coherente con cómo lo hace (o cómo lo hace su equipo).

Son en gran parte intercambiables pero una propiedad le indica al usuario que la implementación es relativamente "simple". Ah, y la sintaxis es un poco más limpia.

En general, mi filosofía es que si comienzas a escribir un nombre de método que comienza con get o set y toma cero o un parámetro (respectivamente), entonces es un candidato principal para una propiedad.

Answer 3

Prefiero usar propiedades para métodos de agregar/configurar con parámetro. Si los parámetros son más, use métodos.

Answer 4

Las propiedades solo se deben establecer de forma simple y obtener uno. Algo más y realmente debería moverse a un método. El código complejo siempre debe estar en los métodos.

Answer 5

Si está configurando una propiedad real de su objeto, entonces utiliza una propiedad.

Si está realizando una tarea/funcionalidad, entonces usa un método.

En su ejemplo, se trata de una propiedad definitiva.

Sin embargo, si su funcionalidad era AppendToLabel, entonces usaría un método.

Answer 6

Las propiedades son realmente agradables porque son accesibles en el diseñador visual de visual studio, siempre que tengan acceso.

Se utilizan si se limita a establecer y obtener y tal vez alguna validación que no acceda a una cantidad significativa de código. Tenga cuidado porque la creación de objetos complejos durante la validación no es simple.

Cualquier otro método es la forma preferida.

No se trata solo de semántica. El uso de propiedades inapropiadas comienza a tener rareza en el diseñador visual visual visual.

Por ejemplo, yo era conseguir un valor de configuración dentro de una propiedad de una clase. La clase de configuración realmente abre un archivo y ejecuta una consulta SQL para obtener el valor de esa configuración. Esto causó problemas en mi aplicación donde el archivo de configuración se abriría y bloquearía por el propio estudio visual en lugar de mi aplicación porque no solo estaba leyendo sino escribiendo el valor de configuración (a través del método setter). Para arreglar esto solo tuve que cambiarlo a un método.

Answer 7

Solo uso propiedades para el acceso variable, es decir, obteniendo y configurando variables individuales, o obteniendo y configurando datos en los controles. Tan pronto como se necesite/realice cualquier tipo de manipulación de datos, uso métodos.

Answer 8

Solo hay que mirar el mismo nombre ... "Propiedad". Qué significa eso? El diccionario lo define de muchas maneras, pero en este caso "un atributo esencial o distintivo o la calidad de una cosa" encaja mejor.

Piensa en el propósito de la acción. ¿Estás, de hecho, alterando o recuperando "un atributo esencial o distintivo"? En su ejemplo, está usando una función para establecer una propiedad de un cuadro de texto. Eso parece un poco tonto, ¿no?

Las propiedades son realmente funciones. Todos compilan hasta getXXX() y setXXX(). Simplemente los oculta en azúcar sintáctico, pero es el azúcar el que proporciona un significado semántico al proceso.

Piensa en propiedades como atributos. Un auto tiene muchos atributos. Color, MPG, Modelo, etc. No todas las propiedades son variables, algunas son calculables.

Mientras tanto, un Método es una acción. GetColor debería ser una propiedad. GetFile() debería ser una función. Otra regla general es que, si no cambia el estado del objeto, entonces debería ser una función. Por ejemplo, CalculatePiToNthDigit (n) debería ser una función, porque en realidad no está cambiando el estado del objeto Math al que está conectado.

Esta es tal vez divagando un poco, pero que realmente se reduce a decidir cuáles son sus objetos son y lo que representan. Si no puede averiguar si debe ser una propiedad o función, tal vez no importe cuál.

Answer 9

propiedades Symantically son atributos de los objetos. Los métodos son comportamientos de su objeto.

Label es un atributo y que tiene más sentido para que sea una propiedad.

En cuanto a la programación orientada a objetos que debe tener una comprensión clara de lo que es parte de la conducta y lo que es meramente un atributo.

coche {color, modelo, marca}

Un coche tiene color, modelo y Atributos de marca por lo que no tiene sentido tener un SetColor método o setModel porque symantically no preguntamos de coches para establecer su propio color .

Por lo tanto, si asigna la propiedad/caso de método al objeto de la vida real o lo mira desde el punto de vista semántico, su confusión realmente desaparecerá.

Answer 10

Las propiedades son una forma de inyectar o recuperar datos de un objeto. Crean una abstracción sobre variables o datos dentro de una clase. Son análogos a getters y setters en Java.

Los métodos encapsulan una operación.

En general, utilizo las propiedades para exponer bits individuales de datos, o pequeños cálculos en una clase, como el impuesto a las ventas. Que se deriva de la cantidad de artículos y su costo en un carrito de compras.

Utilizo métodos cuando creo una operación, como recuperar datos de la base de datos. Cualquier operación que tenga partes móviles, es un candidato para un método.

En el ejemplo de código me envuelve en una propiedad si necesito para acceder a ella afuera es que contiene la clase:

public Label Title 
{ 
    get{ return titleLabel;} 
    set{ titleLabel = value;} 
} 

Ajuste del texto:

Title.Text = "Properties vs Methods"; 

Si sólo era la creación del Texto propiedad de la etiqueta así es como lo haría:

public string Title 
{ 
    get{ return titleLabel.Text;} 
    set{ titleLabel.Text = value;} 
} 

Configuración del texto:

Title = "Properties vs Methods"; 

Answer 11

Como cuestión de las propiedades de diseño representan datos o atributos del objeto de clase, Mientras que los métodos son acciones o comportamientos de objeto de clase.

En .Net, mundo hay otras implicaciones del uso Propiedades:

• Las propiedades se utilizan en la vinculación de datos, mientras que los métodos set_ get_/no lo son.
  
• Propiedades de usuario de serialización XML como mecanismo natural de serilización.
  
• Se accede a las propiedades por PropertyGrid control y pasante ICustomTypeDescriptor, que se pueden utilizar eficazmente si está escribiendo una biblioteca personalizada.
  
• Las propiedades están controladas por Attributes, se puede usar sabiamente para diseñar software orientado a aspectos.

ideas falsas (en mi humilde opinión) sobre el uso de Propiedades:

• Usado para exponer pequeños cálculos: ControlDesigner.SelectionRules 's obtener el bloque se encuentra con 72 líneas !!
  
• Utilizado para exponer estructuras de datos internas: incluso si una propiedad no se asigna a un miembro de datos interno, se puede usar como propiedad, si es un atributo de su clase. Viceversa, incluso si es un atributo de las propiedades de su clase no son aconsejables, para devolver datos como los miembros de datos (en su lugar, los métodos se utilizan para devolver una copia profunda de los miembros.)

En este ejemplo, podría haber sido escrito, con más significado negocio como:

public String Title 
{ 
    set { Label.Text = text; } 
} 

Answer 12

Buscando a través de MSDN, he encontrado una referencia sobre Properties vs Methods que proporciona algunos grandes directrices para la creación de métodos:

• El funcionamiento es una conversión, como Object.ToString.
• El funcionamiento es lo suficientemente caro como para comunicarle al usuario que deberían considerar el almacenamiento en memoria caché como 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 deben poder establecerse y recuperarse 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. Normalmente es necesario devolver una copia de la matriz interna para que el usuario no pueda cambiar el estado interno. Esto, junto con con el hecho de que un usuario puede fácilmente asumir que es una propiedad indexada, conduce a un código ineficiente.

Answer 13

Vengo de Java y uso el método get .. set .. por un tiempo.

Cuando escribo código, no me pregunto: "¿acceder a esta información es simple o requiere un proceso pesado?" porque las cosas pueden cambiar (hoy recuperar esta propiedad es simple, tomonrow puede requerir algún proceso pesado).

Hoy tengo un método SetAge (int age) tomonrow también tendré el método SetAge (date birthdate) que calcula la edad usando la fecha de nacimiento.

Estaba muy decepcionado de que el compilador transforme la propiedad en get y set, pero no considera mis métodos Get ... y Set .. como iguales.

Answer 14

Aquí es un buen conjunto de directrices de cuándo utilizar las propiedades frente a los métodos de Bill Wagner

• utilizar una propiedad cuando todo esto es verdad: Los captadores debe ser simple y por lo tanto poco probable que lanzar excepciones. Tenga en cuenta que esto no implica acceso a la red (o la base de datos). Cualquiera puede fallar y, por lo tanto, lanzar una excepción.
• No deberían tener dependencias entre sí. Tenga en cuenta que esto incluiría establecer una propiedad y hacer que afecte a otra.(Por ejemplo, establecer la propiedad FirstName afectaría a una propiedad FullName de solo lectura que comprenda el nombre + las propiedades del apellido implica tal dependencia)
• Deberían poderse ajustar en cualquier orden
• El captador no tiene un observable efecto secundario Tenga en cuenta que esta guía no excluye algunas formas de evaluación perezosa en una propiedad.
• El método siempre debe regresar inmediatamente. (Tenga en cuenta que esto excluye una propiedad que realiza una llamada de acceso a la base de datos, una llamada al servicio web u otra operación similar).
• Utilice un método si el miembro devuelve una matriz.
• Las llamadas repetidas al captador (sin código intermedio) deberían devolver el mismo valor.

• Las llamadas repetidas al colocador (con el mismo valor) no deberían producir ninguna diferencia con una sola llamada.

• El get no debe devolver una referencia a las estructuras de datos internas (Consulte el elemento 23). Un método podría devolver una copia profunda y podría evitar este problema.

* Tomado de mi respuesta a una pregunta duplicada.

Answer 15

También una gran ventaja para las propiedades es que el valor de la propiedad se puede ver en Visual Studio durante la depuración.