c# datetime初始化 - 为什么DateTime.Now属性而不是方法?




datetime格式化 c#格式 (6)

准则就是这样,而不是硬性规则。

这些指南适用于有状态对象,实际上试图说属性不应该改变对象。 DateTime.Now是一个静态属性,因此调用它不会改变对象。 它也仅仅反映了自然的时间状态,而不是改变任何东西。 它只是观察不断变化的计时器。

所以关键是,不要创建改变对象状态的属性。 创建仅仅观察对象状态的属性(即使状态在外部发生变化)。

作为另一个例子,让我们看一下字符串的长度。 这是一个属性,但是如果其他东西在外部更改字符串,则字符串的长度可以从调用更改为调用。 这基本上是正在发生的事情,计时器正在外部更改,现在只是将其当前状态反映为string.Length或任何其他此类属性。

阅读此博客文章后: http://wekeroad.com/post/4069048840/when-should-a-method-be-a-propertyhttp://wekeroad.com/post/4069048840/when-should-a-method-be-a-property

我想知道为什么微软选择C#:

DateTime aDt = DateTime.Now;

代替

DateTime aDt = DateTime.Now();
  • 最佳实践说:在连续两次调用成员时使用方法会产生不同的结果
  • DateTime.Now是非确定方法/属性的完美示例。

你知道这个设计有什么理由吗?
或者,如果这只是一个小错误?


在决定“方法与属性”时,建议的测试是“将连续调用返回不同的结果”。 我建议更好的测试是类似但不完全相同的问题,“调用例程会影响未来调用相同或不同例程的结果吗?” 在大多数情况下,两个问题的答案都是相同的,因为到目前为止,后来调用例程的最常见原因会产生前者不同的结果,前者会导致后一个调用返回不同的结果。结果比其他情况下要好。

在DateTime.Now的情况下,一个调用将影响另一个调用返回的值的唯一方法是,如果第一个调用所花费的执行时间导致第二个调用发生的时间明显晚于其他情况。 虽然一个学究者可能会认为时间的流逝是第一次调用的状态改变的副作用,但我会建议有许多属性需要比DateTime.Now执行更长的时间,因此调用任何这些属性都会有更改后续DateTime.Now调用返回的值的可能性更大。

请注意,如果“获取时间”例程是虚拟类成员而不是静态成员,那么这将改变平衡,有利于使其成为一种方法; 虽然“预期的”实现不会影响任何对象的状态,但是某些实现可能会产生副作用,或者至少是合理的。 例如,在RemoteTimeServer对象上调用Now可能会尝试从远程服务器获取时间,并且此类尝试可能会对系统的其余部分产生相当大的副作用(例如,通过使一台或多台计算机缓存DNS / IP路由信息) ,这样下一次访问同一服务器的尝试将快100ms完成。


由于没有关于何时使用方法和属性的明线规则,DateTime.Now实际上只是读取服务器状态的公开属性,它可能会不断变化,但DateTime.Now永远不会影响任何属性的状态,对象或什么不是,所以它是框架中的属性。


我相信CLR通过C#,Jeffrey Richter提到DateTime.Now是一个错误。

System.DateTime类具有readonly Now属性,该属性返回当前日期和时间。 每次查询此属性时,它将返回不同的值。 这是一个错误,Microsoft希望他们可以通过将Now设为方法而不是属性来修复该类。

CLR通过C#第3版 - 第243页


根据MSDN,当某些东西是对象的逻辑数据成员时,您应该使用属性:

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

继续列出方法更合适的情况。 具有讽刺意味的是,方法的一个规则是在连续调用可能返回不同结果时使用它,当然现在肯定符合该标准。

我个人认为这是为了消除extra()的需要,但我发现没有()令人困惑; 我花了一些时间从VB / VBA中的旧方法转变。


When they say List<T> is "optimized" I think they want to mean that it doesn't have features like virtual methods which are bit more expensive. So the problem is that once you expose List<T> in your public API , you loose ability to enforce business rules or customize its functionality later. But if you are using this inherited class as internal within your project (as opposed to potentially exposed to thousands of your customers/partners/other teams as API) then it may be OK if it saves your time and it is the functionality you want to duplicate. The advantage of inheriting from List<T> is that you eliminate lot of dumb wrapper code that is just never going to be customized in foreseeable future. Also if you want your class to explicitly have exact same semantics as List<T> for the life of your APIs then also it may be OK.

I often see lot of people doing tons of extra work just because of FxCop rule says so or someone's blog says it's a "bad" practice. Many times, this turns code in to design pattern palooza weirdness. As with lot of guideline, treat it as guideline that can have exceptions.





c# .net datetime