I like the singleton pattern, but not singleton classes nor static classes. The latter do not lend to good testability in TDD.
The singleton pattern, when implemented with something like DI or the registry pattern, does give good testability. On 7/17/06, Shawn Wildermuth <[EMAIL PROTECTED]> wrote:
In much of the past five years, I have created a number of static classes to handle processing-only functionality. I end of hearing objections to using a static class, where others might prefer to use a singleton. As far as I can tell, a singleton and a static class are close to identical though the singleton class tend to have more plumbing and make it easier to save state (which I am generally opposed to). What are the opinions about the best practices of Static classes versus singletons? Generally I am talking about classes that do not have state so problems like cross AppDomain instancing or Remoted instances never come into view, but I am open to views that take those into account as well.
-- Brad Wilson http://www.agileprogrammer.com/dotnetguy/ "Constraints are liberating." - David Heinemeier Hansson (author of Ruby on Rails) =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
