2009-12-06 11 views
11

Duplicar posibles:
Properties vs Methods¿Cuándo usar una propiedad frente a un método?

¿Hay alguna regla o mejor práctica general en cuanto a cuándo utilizar una propiedad frente a un método? Técnicamente, cualquier método sin parámetros se puede hacer en una propiedad y cualquier propiedad se puede convertir en un método, pero a veces, cuando se puede decidir cuándo usar uno de los otros puede ser borroso.

Esperaba obtener algunas reglas que ustedes tuvieron en cuenta al decidir entre los dos.

Respuesta

12

El estándar general está sobre efectos secundarios. Si llamando a un miembro para obtener un valor solo obtiene ese valor, es una propiedad. Si hay efectos secundarios, probablemente debería ser un método.

Dicho de otra manera: las propiedades aunque no sean campos deberían comportarse de manera muy similar a los campos. Esto significa no causar efectos secundarios, no tomar demasiado tiempo para ejecutar y no lanzar excepciones.

+6

¿No arrojando excepciones? ¿Qué harías si el valor establecido fuera un valor no válido? Pensé que esa era una de las razones para usar propiedades sobre los campos ... la capacidad de verificar el valor antes de aceptarlo. – Svish

5

Para agregar a lo que ha dicho cletus.

Esto es de MSDN: "El uso de directrices de propiedad" http://msdn.microsoft.com/en-us/library/bzwdh01d(VS.71).aspx Ver la sección "Propiedades vs. Métodos":

  • La operación es una conversión, como Object.ToString.
  • La operación es lo suficientemente costosa como para que desee comunicarle al usuario que debe considerar almacenar en caché el 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 se deben poder establecer y recuperar 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. Por lo general, es necesario devolver una copia de la matriz interna para que el usuario no pueda cambiar el estado interno. Esto, junto con el hecho de que un usuario puede asumir fácilmente que es una propiedad indexada, conduce a un código ineficiente. En el siguiente ejemplo de código, cada llamada a la propiedad Methods crea una copia de la matriz. Como resultado, 2n + 1 copias de la matriz se crearán en el siguiente ciclo.
1

utilizan la propiedad cuando algunos er .. la propiedad tiene un rendimiento rápido (por ejemplo, ctrl.Color, ctrl.Text, ctrl.Width, DateTime.Now). pero si significa un proceso, use el método (por ejemplo, str.GetHash(), machine.GetFqdn(), file.GetMd5()). por lo que en MD5 archivo, no lo hará una propiedad

este enfatizar que es el más when to use a method:

El funcionamiento es bastante caro que desea comunicar al usuario que deberían considerar el almacenamiento en caché de la resultado.

tenga en cuenta .NET's DateTime.Ahora, aunque es rápido y es una propiedad, debe almacenarse en caché cuando se lo llama varias veces en su programa, incluso cerca el uno del otro. decidieron convertirlo en una propiedad, la propiedad tiene una sensación de currentness en ella, a diferencia de cuando llama a un método, no tiene una sensación de instantness/currentness en él. por lo que debe tener en cuenta que incluso cuando obtiene un valor y necesita ser almacenado en la memoria caché, pero si necesita sentir instantánea, utilice la propiedad.

después de todo, si algo es realmente rápido y no se siente como una operación costosa, tiene que tener una construcción que pueda transmitir su solidez. Creo que esta es la razón por la cual .NET es atractivo (o cualquier lenguaje que tenga una construcción de propiedad), no obliga a los desarrolladores a usar el método cuando puedes convertirlo en una propiedad, no obliga a los desarrolladores a usar el método cuando puedes hacer un código de rendimiento alrededor de operadores sobrecargados, esta es la programación pragmática en su mejor

0

es una buena pregunta. No conozco ninguna buena práctica sobre esto. En mi opinión, generalmente se trata de un sentido común.

Las propiedades están relacionadas con el objeto/clase en sí mismo y generalmente lo describen. El mejor ejemplo del elemento UI, Background, Color, IsEnabled es de propiedad.

Los métodos son generalmente acciones que el objeto/clase puede realizar y puede generar resultados. El mejor ejemplo aquí es el método Show de un MessageBox. hace una acción y devuelve un resultado.

0

En el nivel fundamental, la decisión entre elegir una propiedad o método depende del argumento 'tiene', 'no'. Si la información que necesita es un atributo o calidad, vaya con propiedades. Si es una acción, entonces métodos.

Pero a nivel práctico puede ser difícil implementarlo de esta manera todo el tiempo.

  • Como se ha señalado con acierto, las propiedades deben ser livianas, los métodos no tienen por qué serlo.
  • Si la información depende de algún código de inicialización llamado en un constructor, entonces debería preferir una propiedad.
  • Si su información necesita muchas operaciones, use los métodos.
  • Si afecta a un tercer elemento como un archivo, o la pantalla o algo así, use los métodos.
  • No puede tener propiedades que no devuelvan nada (nulas).
0

Diciéndolo con palabras básicas, una propiedad describe el objeto, mientras que un método es una acción que el objeto puede hacer. Para un objeto que representa un automóvil, drive() sería un método, y color sería una propiedad.

Cuestiones relacionadas