Static classes and singleton objects

In object oriented programming languages, I like the Singleton pattern, and I also like the static concept. But I think there are some unfortunate misuses, or arguably just poor terminiology, mixed up with both of them.

The static concept does (or should…) mean, any characteristic or functionality of a class that doesn’t change, and/or, any characteristic or functionality that is independent of any particular instance of that class. However, static functions are often piled into a class that is never instantiated, and effectively becomes a glorified library. It’s great that Java provides so much standard functionality, but come on, the Math class is not object oriented at all, it’s just a convenient place to put a bunch of tools. Don’t get me wrong, the way that Java handles namespaces is great. But to call Math a class is just silly. (Or am I wrong? Does Math have a bunch of extension classes that depend on its structure and namespace in order to be designed well?)

Second, I’ve never used the singleton pattern in a class that was also arbitrarily instantiable. If a class can be used as a singleton, then it should only be used as a singleton. And while it’s nice to think of a singleton object as a “real” object, with the same presense and role as the other objects that interact with it, this is really just for the conceptual pleasure of the programmer. (Actually this makes me think of a side concern: is a singleton object just a glorified set of static members and methods, similar to all-static classes like Math? I.E., have you ever designed a singleton object that changed state at runtime?).

I propose two features that I want to see in OO languages that would cut down on a lot of redundant syntax:

  1. A “library” concept. (Perhaps call it something other than library, to avoid confusion with how people label various other projects and tools. Maybe “toolset”). This would be what we today call a uninstantiable class with only static methods. The advantage would be purely conceptual and syntactic (no need to declare everything static). It would save beginners some headache, programmers some time, and programs some clutter.
  2. The singleton concept supported at the language level. For example:

    protected singleton class NullNode extends LinkedListNode{ ... }

    Now, to refer to the singleton, instead of any ridiculous bussiness such as NullNode.singleton or NullNode::singleton(), one could simply refer to NullNode.

1 Response to “Static classes and singleton objects”


  1. 1 Jeff

    I’m confused by your singleton comment. Why isn’t a singleton object a real object? And why wouldn’t you feel free to change its state at runtime?

Leave a Reply




Close
Powered by ShareThis