metodos - propiedad virtual c#
Para usar una propiedad de solo lectura o un método? (12)
Creo que esta línea en tu enlace es la respuesta
los métodos representan acciones y las propiedades representan datos.
No hay acción aquí, solo un dato. Entonces es una propiedad.
Necesito exponer el estado "¿ está mapeado? " De una instancia de una clase. El resultado está determinado por un control básico. No se trata simplemente de exponer el valor de un campo. No estoy seguro si debería usar una propiedad de solo lectura o un método.
Propiedad de solo lectura:
public bool IsMapped
{
get
{
return MappedField != null;
}
}
Método:
public bool IsMapped()
{
return MappedField != null;
}
Leí MSDN''s Choosing Between Properties and Methods, pero aún no estoy seguro.
El estándar de C # dice
§ 8.7.4
Una propiedad es un miembro que proporciona acceso a una característica de un objeto o una clase. Los ejemplos de propiedades incluyen la longitud de una cadena, el tamaño de una fuente, el título de una ventana, el nombre de un cliente, etc. Las propiedades son una extensión natural de los campos. Ambos son miembros nombrados con tipos asociados, y la sintaxis para acceder a campos y propiedades es la misma. Sin embargo, a diferencia de los campos, las propiedades no denotan ubicaciones de almacenamiento. En cambio, las propiedades tienen accesadores que especifican las declaraciones que se ejecutarán cuando se leen o escriben sus valores.
mientras que los métodos se definen como
§ 8.7.3
Un método es un miembro que implementa un cálculo o acción que puede realizar un objeto o clase. Los métodos tienen una lista (posiblemente vacía) de parámetros formales, un valor de retorno (a menos que el tipo de devolución del método sea nulo) y son estáticos o no estáticos.
Las propiedades y los métodos se utilizan para realizar la encapsulation . Las propiedades encapsulan datos, los métodos encapsulan la lógica. Y esta es la razón por la que debería preferir una propiedad de solo lectura si está exponiendo datos. En su caso, no existe una lógica que modifique el estado interno de su objeto. Desea proporcionar acceso a una característica de un objeto .
Si una instancia de su objeto IsMapped o no es una característica de su objeto. Contiene un cheque, pero es por eso que tiene propiedades para acceder a él. Las propiedades se pueden definir utilizando la lógica, pero no deberían exponer la lógica. Al igual que el ejemplo mencionado en la primera cita: Imagine la propiedad String.Length . Dependiendo de la implementación, es posible que esta propiedad recorra la cadena y cuente los caracteres. También realiza una operación, pero "desde afuera" simplemente da una declaración sobre el estado / características internas del objeto.
En este caso, parece bastante claro para mí que debería ser una propiedad. Es una comprobación simple, sin lógica, sin efectos secundarios, sin impacto en el rendimiento. No es mucho más simple que esa verificación.
Editar:
Tenga en cuenta que si hubiera algo de lo mencionado anteriormente y lo pondría en un método, ese método debería incluir un verbo fuerte, no un verbo auxiliar como es o tiene. Un método hace algo. Podría ponerle el nombre VerifyMapping o DetermineMappingExistance u otra cosa, siempre que comience con un verbo.
En mi humilde opinión, la primera propiedad de solo lectura es correcta porque IsMapped es un Atributo de su objeto, y no está realizando una acción (solo una evaluación), pero al final del día la consistencia con su base de código existente probablemente cuente por más de semántica ... a menos que esto sea una asignación uni
En situaciones / idiomas en los que tiene acceso a estos dos constructos, la división general es la siguiente:
- Si la solicitud es para algo que tiene el objeto, use una propiedad (o un campo).
- Si la solicitud es para el resultado de algo que hace el objeto, use un método.
Un poco más específicamente, una propiedad se debe usar para acceder, en forma de lectura y / o escritura, a un miembro de datos que es (para fines de consumo) propiedad del objeto que expone la propiedad. Las propiedades son mejores que los campos porque los datos no tienen que existir en forma persistente todo el tiempo (le permiten ser "flojo" sobre el cálculo o la recuperación de este valor de datos), y son mejores que los métodos para este fin porque aún puede usarlos en el código como si fueran campos públicos.
Las propiedades no deben, sin embargo, dar lugar a efectos secundarios (con la posible excepción comprensible de establecer una variable destinada a persistir el valor que se devuelve, evitando el costoso recálculo de un valor necesario muchas veces); deberían, en igualdad de condiciones, devolver un resultado determinista (por lo que NextRandomNumber es una mala elección conceptual para una propiedad) y el cálculo no debería dar como resultado la alteración de los datos de estado que afectarían a otros cálculos (por ejemplo, obtener PropertyA y PropertyB en ese orden no debería arrojar ningún resultado diferente que obtener PropertyB y luego PropertyA).
Un método, OTOH, se entiende conceptualmente como realizar alguna operación y devolver el resultado; en resumen, hace algo, que puede extenderse más allá del alcance de calcular un valor de retorno. Los métodos, por lo tanto, se deben usar cuando una operación que devuelve un valor tiene efectos secundarios adicionales. El valor de retorno puede seguir siendo el resultado de algún cálculo, pero el método puede haberlo calculado de manera no determinista (GetNextRandomNumber ()), o los datos devueltos tienen la forma de una instancia única de un objeto, y llamar al método nuevamente produce una instancia diferente, incluso si puede tener los mismos datos (GetCurrentStatus ()), o el método puede alterar datos de estado de manera que hacer exactamente lo mismo dos veces seguidas produce resultados diferentes (EncryptDataBlock (); muchos cifrados funcionan de esta manera diseño para asegurar que encriptar los mismos datos dos veces seguidas produce diferentes textos cifrados).
Esperaría una propiedad ya que solo devuelve el detalle de un campo. Por otro lado, esperaría
MappedFields[] mf;
public bool IsMapped()
{
mf.All(x => x != null);
}
Estaré de acuerdo con la gente aquí al decir que, como está obteniendo datos, y no tiene efectos secundarios, debería ser una propiedad.
Para ampliarlo, también aceptaría algunos efectos secundarios con un setter (pero no con un getter) si los efectos colaterales tienen sentido para alguien que "lo mira desde afuera".
Una forma de pensarlo es que los métodos son verbos y las propiedades son adjetivos (mientras tanto, los objetos en sí son sustantivos y los objetos estáticos son sustantivos abstractos).
La única excepción a la directriz verbo / adjetivo es que puede tener sentido utilizar un método en lugar de una propiedad cuando obtener (o establecer) la información en cuestión puede ser muy costoso: lógicamente, tal característica probablemente todavía sea una propiedad, pero la gente está acostumbrada a pensar en las propiedades como de bajo impacto en cuanto a rendimiento y aunque no hay una razón real por la que ese debería ser siempre el caso, podría ser útil resaltar que GetIsMapped() es relativamente pesado en cuanto a rendimiento si de hecho .
En el nivel del código en ejecución, no hay absolutamente ninguna diferencia entre llamar a una propiedad y llamar a un método equivalente para obtener o establecer; se trata de hacer la vida más fácil para la persona que escribe el código que lo usa.
Personalmente creo que un method debería hacer algo o realizar alguna acción. No está realizando nada dentro de IsMapped por lo que debería ser una property
Si en algún momento necesitarás agregar parámetros para obtener el valor, entonces necesitas un método. De lo contrario, necesitas una propiedad
Usaría la propiedad, porque no hay un "hacer" (acción) real, no hay efectos secundarios y no es demasiado complejo.
Yo iría por una propiedad. Sobre todo porque la primera senctencia en el artículo MSDN referenciado:
En general, los métodos representan acciones y las propiedades representan datos.
deberías usar la propiedad porque c # tiene propiedades por este motivo