http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660A pattern so common and useful as singleton is should be part of the language, as they do in Scalahttp://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment14http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment14Sat, 10 Nov 2012 13:56:09 GMT@James C-S Write a unit test that asserts on the behavior when the date is "yesterday".http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment13http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment13Fri, 02 Nov 2012 03:06:46 GMTCan you provide some more detail as to why `DateTime.Now` has hidden dependencies?http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment12http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment12Fri, 02 Nov 2012 01:07:51 GMTRafal: That is a matter of definition. I see nothing wrong in defining it as a singleton in the request-scope. A lot of other people do the same.http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment11http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment11Thu, 01 Nov 2012 14:13:20 GMTHttpContext.Current and DateTime.Now were given as examples of "hidden dependencies", not singletons..http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment10http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment10Thu, 01 Nov 2012 13:19:43 GMT@AndersM One instance per request is not the same as single instance. For example, httprequest.current is not shared by multiple threads... And what about DateTime.Now - where's the singleton?http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment9http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment9Wed, 31 Oct 2012 17:18:08 GMTDateTime.Now is not a singelton, I would consider it a static property/factory of some sort... You are getting a different instance on every callhttp://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment8http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment8Wed, 31 Oct 2012 15:41:45 GMT// Haiku class Singleton { private Singleton(){} public static readonly Singleton Current = new Singleton(); } http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment7http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment7Wed, 31 Oct 2012 15:41:40 GMT"per request" -> not "per appdomain" (at least) -> no singletonhttp://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment6http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment6Wed, 31 Oct 2012 15:01:20 GMTDada: Yes, you get the singleton through the static property, but the returned object is still a singleton. There is only one httpcontext per request.http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment5http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment5Wed, 31 Oct 2012 14:50:02 GMTAs Patrick alluded, the biggest problem with the Singleton pattern is in how it is misapplied as an access "pattern". If we follow the classification that the GOF gave it, Singleton is a *creational* pattern. Period. Unfortunately, most folks see a public getInstance() or Current member and think they've found a geek-sanctioned way to implement global variables. Second, it is an *implementation* concern. Just like any other implementation concern, that concern shouldn't be exposed to client code. Simply put, the only code that should care something is a singleton, is the singleton itself. Every other piece of code should depend on receiving an actual reference to an instance.http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment4http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment4Wed, 31 Oct 2012 13:50:39 GMT"Probably the most famous of them was HttpContext.Current" HttpContext.Current is not an example of a singleton, just an example of a public static prop.http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment3http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment3Wed, 31 Oct 2012 13:28:35 GMT>Common workaround to that is to break apart the notion of accessing the value and the single nature of the value. So you typically inject the value in, and something else, usually the container, is in charge of managing the lifetime of the object. I agree 100% with you on that. But static access to singleton object is really part of the DP Singleton in the mind of all developers. So I'd suggest giving a different name like Single Instance Pattern or Manager Pattern to what you describe. Singleton per-se makes the code highly un-testable. More generally the 'static' keyword should be use with great care, here are my recommendations: http://codebetter.com/patricksmacchia/2009/11/16/back-to-basics-usage-of-static/http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment2http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment2Wed, 31 Oct 2012 12:04:34 GMTIsn't there a difference between the Singleton Pattern and a singleton lifetime? The pattern is always connected with the global static accessor while the lifetime is something that has to be managed by an external instance (like a di container).http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment1http://ayende.com/159426/design-patterns-in-the-test-of-time-singleton#comment1Wed, 31 Oct 2012 10:15:26 GMT