>Humm, let me try to convey my meaning very explicitly: if your class
>has *only* static methods, then it should be a static class.
>Otherwise, it should probably be a singleton for all the previous
>mentionned reasons. I would not like to see XyzUtility.Instance or
>Algorithms.Instance or Math.Instance pop everywhere in my code, this
>looks just wrong to me.
I see this as an interface issue, rather than a singleton issue. As an example:
class Singleton
{
/// singleton stuff here
/// ...
/// ...
public static void Foo()
{
return Instance.doFoo();
}
protected void doFoo() {}
}
There's no reason for the client to call Singleton.Instance, it might even
be protected. I've just provided a static interface that forwards to the
protected instance interface. The client has no idea they're not using a
static class.
>Maybe it is just me, but keeping state in a static class has bitten me
>too many times (cold startup time, possible memory leaks, remoting
>issues, threading issues, etc.). You do not always have the luxury of
>changing the public signature of your components ... especially if you
>are designing a core application framework that will be used in many
>large projects.
Absolutely true, although lazy evaluation techniques can alleviate your
startup times. When I talk about .net I'm generally thinking in C# terms
(and mostly in ASP.NET terms, because that is what I do). I worry more about
resource leaks than memory leaks. Threading issues apply to both static
classes and static singleton instances similarly. Your point about changing
signatures and core frameworks is absolutely true as well, though I was
thinking about private static data, not public static data.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
