sirve - propiedades de una clase c#

¿Por qué DateTime.Now es una propiedad y no un método?

Question

Después de leer esta entrada del blog: http://wekeroad.com/post/4069048840/when-should-a-method-be-a-property ,

Me pregunto por qué Microsoft elige en C #:

DateTime aDt = DateTime.Now;

en lugar de

DateTime aDt = DateTime.Now();

• Las mejores prácticas dicen: Use un método cuando llamar al miembro dos veces seguidas produce resultados diferentes
• Y DateTime.Now es el ejemplo perfecto de método / propiedad no determinística.

¿Sabes si hay alguna razón para ese diseño?
O si es solo un pequeño error?

Answer 1

Al decidir "método versus propiedad", una prueba sugerida es "las llamadas sucesivas devolverán resultados diferentes". Yo sugeriría que una prueba mejor es la pregunta similar, pero no idéntica: "¿afectará la llamada a la rutina el resultado de las futuras llamadas a la misma o diferente rutina?" En la mayoría de los casos, las respuestas a ambas preguntas serán las mismas, ya que la razón más común por la que las llamadas posteriores a una rutina arrojarán resultados diferentes de la anterior sería que la primera provocó que la llamada posterior devolviera un resultado diferente. resultado que de otra manera tendría.

En el caso de DateTime.Now, la única forma en que una llamada afectaría el valor devuelto por otra sería si el tiempo de ejecución tomado por la primera llamada provoca que la segunda llamada se produzca mensurablemente más tarde de lo que lo hubiera hecho. Mientras que un pedante puede considerar el paso del tiempo como un efecto colateral que altera el estado de la primera llamada, sugeriría que hay muchas propiedades que tardan más en ejecutarse que DateTime.Now, y por lo tanto una llamada a cualquiera de ellas tendría una mayor probabilidad de cambiar el valor devuelto por una llamada DateTime.Now posterior.

Tenga en cuenta que si la rutina "obtener tiempo" fuera un miembro de clase virtual en lugar de ser un miembro estático, eso cambiaría el equilibrio a favor de convertirlo en un método; mientras que la implementación "esperada" no afectaría el estado de ningún objeto, sería probable, o al menos plausible, que algunas implementaciones tuvieran efectos colaterales. Por ejemplo, llamar ahora a un objeto RemoteTimeServer podría intentar obtener la hora de un servidor remoto, y dicho intento podría tener considerables efectos secundarios en el resto del sistema (por ejemplo, al hacer que una o más máquinas guarden en caché la información de enrutamiento DNS / IP) , de modo que el próximo intento de acceder al mismo servidor finalizará 100 ms más rápido).

Answer 2

Como no hay reglas brillantes sobre cuándo usar un método y una propiedad, DateTime.Now solo está leyendo una propiedad expuesta del estado del servidor, puede estar cambiando constantemente, pero DateTime.Now nunca afecta el estado de ninguna propiedad. , objeto o lo que no, por lo que es una propiedad en el Marco.

Answer 3

Creo en CLR a través de C #, Jeffrey Richter menciona que DateTime.Now es un error.

La clase System.DateTime tiene una propiedad Readonly Now que devuelve la fecha y la hora actuales. Cada vez que consulta esta propiedad, devolverá un valor diferente. Esto es un error, y Microsoft desea que puedan arreglar la clase haciendo de Now un método en lugar de una propiedad.

CLR vía C # 3rd Edition - Página 243

Answer 4

En realidad es determinista; su salida no es aleatoria, sino que se basa en algo bastante predecible.

La ''hora actual'' cambia todo el tiempo; así que para ser relativamente "lo mismo" con cada llamada, ese valor debe cambiar para que cada vez que se invoca, devuelva la hora actual.

EDITAR:

Esto simplemente se me ocurrió: por supuesto, dos llamadas posteriores a un comprador de propiedades pueden devolver resultados diferentes, si algo cambió el valor de la propiedad en el ínterin. Las propiedades no se supone que sean Constants .

Entonces, eso es lo que sucede (conceptualmente) con DateTime.Now ; su valor se cambia entre las siguientes llamadas a él.

Answer 5

Las pautas son solo eso, no son reglas duras y rápidas.

Esas directrices están destinadas a objetos con estado, y en realidad intentan decir que las propiedades no deben mutar un objeto. DateTime.Now es una propiedad estática, por lo que llamarlo no muta un objeto. También refleja simplemente el estado natural del tiempo, sin cambiar nada. Simplemente está observando un temporizador que cambia constantemente.

Entonces, el punto es que no crees propiedades que cambien el estado del objeto. Crea propiedades que simplemente observen el estado del objeto (incluso si el estado cambia externamente).

Como otro ejemplo, veamos la longitud de una cadena. Esta es una propiedad, pero la longitud de la cadena puede cambiar de invocación a invocación si algo más cambia la cadena externamente. Eso es básicamente lo que está sucediendo, el temporizador se está cambiando externamente, ahora solo refleja su estado actual igual que string.Length o cualquier otra propiedad similar.

Answer 6

Según MSDN debe usar una propiedad cuando algo es un miembro de datos lógicos del objeto:

http://msdn.microsoft.com/en-us/library/bzwdh01d%28VS.71%29.aspx#cpconpropertyusageguidelinesanchor1

Continúa para enumerar los casos donde un método sería más apropiado. Lo que es irónico es que una de las reglas para un método es usarlo cuando las llamadas sucesivas pueden devolver resultados diferentes y, por supuesto, ahora ciertamente cumple con ese criterio.

Personalmente, creo que esto se hizo para eliminar las necesidades del extra (), pero he encontrado la ausencia de () confuso; Me tomó un poco de tiempo pasar del viejo enfoque en VB / VBA.