Pregunta

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 en las que es discutible si debemos usar una propiedad o un método. Un ejemplo es este:

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 gobernar la decisión (en este caso) de hacer de esto un método o una propiedad?

Aceptaré la respuesta que es más general y completa, pero que también toca el ejemplo que he dado.

¿Fue útil?

Solución

De la Elegir entre propiedades y métodos sección de Pautas de diseño para el desarrollo de bibliotecas de clases:

  

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

Otros consejos

Sí, si todo lo que está haciendo 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 captador toma parámetros o su configurador toma más que un parámetro de valor.

En el centro hay un área gris donde la línea puede ser un poco borrosa. No existe una regla estricta 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) consistente con la forma en que usted lo hace (o cómo lo hace su equipo).

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

En términos generales, mi filosofía es que si comienza a escribir un nombre de método que comienza con obtener o establecer y toma cero o un parámetro (respectivamente), es un candidato principal para una propiedad.

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

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

En tu ejemplo, es una propiedad definida que se establece.

Sin embargo, si tu funcionalidad fuera anexar a la etiqueta, entonces usarías un método.

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 los captadores y establecedores en Java.

Los métodos encapsulan una operación.

En general, uso propiedades para exponer bits de datos individuales o pequeños cálculos en una clase, como el impuesto a las ventas. Lo que se deriva del número 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 candidata para un método.

En su ejemplo de código, lo envolvería en una propiedad si tuviera que acceder fuera de la clase que contiene:

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

Configuración del texto:

Title.Text = "Properties vs Methods";

Si solo estuviera configurando la propiedad de Texto 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";

Buscando en MSDN, encontré una referencia en Propiedades vs Métodos que proporciona algunas pautas geniales para crear métodos:

  
      
  • La operación es una conversión, como Object.ToString .
  •   
  • La operación es lo suficientemente cara como para que quiera comunicarse con el   usuario que deberían considerar el almacenamiento en caché   el resultado.
  •   
  • La obtención de un valor de propiedad utilizando el descriptor de acceso de obtención tendría un observable   efecto secundario.
  •   
  • 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   ser capaz de ser configurado y recuperado 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ñoso Por lo general es   necesario devolver una copia de la   matriz interna para que el usuario no puede   Cambiar estado interno. Esto, acoplado   con el hecho de que un usuario puede fácilmente   Supongamos que es una propiedad indexada,   conduce a un código ineficiente.
  •   

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

La etiqueta es un atributo y tiene más sentido convertirla en una propiedad.

En términos de Programación Orientada a Objetos, debe tener una comprensión clara de qué es parte del comportamiento y qué es simplemente un atributo.

Coche {Color, Modelo, Marca}

Un automóvil tiene atributos de Color, Modelo y Marca, por lo tanto, no tiene sentido tener un método SetColor o SetModel porque, de manera simpática, no le pedimos a Car que establezca su propio color.

Entonces, si asignas el caso de propiedad / método al objeto de la vida real o lo miras desde un punto de vista simbólico, tu confusión realmente desaparecerá.

Solo necesita ver el nombre mismo ... " Propiedad " ;. Qué significa eso? El diccionario lo define de muchas maneras, pero en este caso "un atributo o calidad esencial o distintiva de una cosa" encaja mejor.

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

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

Piensa en propiedades como atributos. Un coche tiene muchos atributos. Color, MPG, modelo, etc. No todas las propiedades son estables, algunas son calculables.

Mientras tanto, un Método es una acción. GetColor debe 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á vinculado.

Esto es quizás un poco incómodo, pero realmente se reduce a decidir cuáles son tus objetos y qué representan. Si no puede averiguar si debería ser una propiedad o función, tal vez no importa cuál.

Prefiero usar las propiedades para agregar / configurar métodos con el parámetro 1 . Si los parámetros son más, usa métodos.

Las propiedades solo deben configurarse de forma simple y obtener una línea. Algo más y realmente debería ser movido a un método. El código complejo siempre debe estar en los métodos.

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

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.

Las propiedades son realmente agradables porque están disponibles en el diseñador visual de Visual Studio, siempre que tengan acceso.

Se usan para ser usados ??simplemente está configurando y obteniendo y quizás alguna validación que no tiene acceso 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 rarezas en el diseñador visual de visual studio.

Por ejemplo, estaba obteniendo 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 de SQL para obtener el valor de esa configuración. Esto causó problemas en mi aplicación donde Visual Studio en sí mismo abriría y bloquearía el archivo de configuración en lugar de mi aplicación porque no solo estaba leyendo sino que también escribía el valor de configuración (a través del método de establecimiento). Para arreglar esto solo tuve que cambiarlo a un método.

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

En .Net, el mundo tiene otras implicaciones de usar Propiedades:

  • Las propiedades se utilizan en Databinding, mientras que los métodos get_ / set_ no lo son.
  • Propiedades de usuario de serialización XML como mecanismo natural de serilización.
  • Se accede a las propiedades mediante PropertyGrid control e interno ICustomTypeDescriptor , que puede usarse de manera efectiva si está escribiendo una biblioteca personalizada.
  • Las propiedades están controladas por Atributos , uno puede usarlo sabiamente para diseñar software orientado a Aspectos.

Conceptos erróneos (IMHO) sobre el uso de las propiedades:

  • Se utiliza para exponer pequeños cálculos: ControlDesigner.SelectionRules se ejecuta en 72 líneas.
  • Se utiliza 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 no es aconsejable que sea un atributo de las propiedades de su clase, devolver elementos de datos similares a una matriz (en lugar de eso, los métodos se utilizan para devolver copias detalladas de los miembros).

En el ejemplo aquí se podría haber escrito, con un significado más comercial como:

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

Aquí hay un buen conjunto de pautas para cuándo usar las propiedades frente a los métodos de Bill Wagner

  • Usa una propiedad cuando todos estos son verdaderos: Los captadores deben ser simples y, por lo tanto, poco propensos a lanzar excepciones. Tenga en cuenta que esto implica que no hay acceso a la red (o base de datos). Cualquiera podría fallar y, por lo tanto, produciría una excepción.
  • No deben 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 una propiedad FullName de solo lectura que compuso las propiedades first name + last name implica tal dependencia)
  • Deben ser configurables en cualquier orden
  • El captador no tiene un efecto secundario observable. 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 de servicio web u otra operación similar).
  • Use un método si el miembro devuelve una matriz.
  • Las llamadas repetidas al captador (sin el código de intervención) deben devolver el mismo valor.
  • Las llamadas repetidas al definidor (con el mismo valor) no deberían generar diferencias con una sola llamada.

  • El método 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.

Esto es simple.

1: use la propiedad cuando desee que sus datos se validen antes de guardarlos en el campo. De esta manera, la propiedad proporciona encapsulación para sus campos. Porque si deja sus campos, el usuario final puede asignar cualquier valor que pueda o no ser válido según los requisitos de su negocio, ya que la edad debería ser mayor que 18. Por lo tanto, antes de guardar el valor, el campo correspondiente debe verificar su validez. De esta manera las propiedades representan datos.

2: Use el método cuando desee realizar alguna acción, ya que está suministrando algunos datos como parámetro y su método está procesando en función de los valores suministrados y devolviendo el valor procesado como resultado. O quieres cambiar el valor de algún campo por este cálculo. " De esta manera, el método representa acción " ;.

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

Cuando escribo un código, no me pregunto: "acceder a estos datos es simple o requiere un proceso pesado" " porque las cosas pueden cambiar (hoy recuperar esta propiedad es simple, Tomonrow puede requerir algunos procesos o procesos pesados).

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

Me decepcionó mucho que la propiedad de transformación del compilador en get and set, pero no considere mis métodos Get ... y Set .. como iguales.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top