Tanguy, Robert, et al: Some good points have been raised by both sides. Singletons should be used carefully, but are still useful in certain circumstances.
For the most part, it is a design decision - that is, it must be determined at the highest design level whether it makes sense to allow multiple instances of something to exist within a single process. Yes, only having one of some object may "limit" certain features, but the point is what the original design calls for - programs and libraries are not uber-omni-functional; they are designed for a specific purpose. It is best to maintain genericism, but only within the original purpose. Let's look at any registry-type object. Does it make sense within a design to have multiple registries? Well, this depends on the design. Is this registry intended to be a sort of "index" for objects or functions loaded at runtime? If this is the case, a singleton registry makes the most sense. It exists as a single object for any process, indexing all functions/object types/whatever with only the appropriate register and accessor functionality built-in. Certain forms of factory design may make good use of such a structure. But what if you want multiple index-type factories? Consider what little there is to be gained from having more than one of these objects - the ability to reference different objects/functions/etc by using the exact same identifier (key/index/whatever). But is it a good thing to even allow such ambiguity? That would mean that there were two items that registered using the same exact identifier, and both were accessible from the same calling application. Unless you have a very specific requirement to allow for non-unique identifiers, it would generally be seen as "bad" to have several distinct items referred to with the exact same identifier, only separated by the specific instance of an accessor/registry object. Sort of like having a global and a local variable with the exact same name, even though they denote entirely different things. Yes, you can do it, but why would you choose to it? Now, on the other hand, some type of "global" state-manager class may seem like a good candidate for singleton usage as well. However, this would only be true in the rare case where there absolutely cannot be more than one handled "state". For example, a OGL context manager could seem to operate in a singleton capacity if you think in terms of a single window with a single context per application - and such thinking could be reasonable some years ago. But nowadays, we routinely open multiple windows with multiple contexts. Thus, a singleton is a poor choice here. Basically, IMO, singletons are suited to objects used only as interfaces to some other set of objects or functionality. For example, an API class for a DLL, as the only exposed interface containing accessor functions. Of course, if it only contains functions, then they could just be placed into a namespace without a class (and hence no singleton), but if resource reference counting or something similar was desired to track usage of the DLL API, then a singleton would make sense. Simiarlly, an "auto-register" factory class which loads some sort of plugin objects at runtime would make a lot of sense as a singleton. These are classes which contain minimal internal functionality, serving primarily to interface some indexed data. Oh, and to the question of how to "reset" the library; if you are using OSG in a runtime-loaded DLL, you could force a reload by freeing and loading the library fresh. (I don't have experience with dynamic linking in non-Windows environments, but there may be analogous procedures available in other systems.) Really, when you think about it, truly returning to the same "clean slate" you started when a library was first loaded is generally a complicated matter; if you really do need the original state, the best way to guarantee it is to completely reload the library itself. Yes, OSG could be equipped with the capability to fully clean up and reset itself, but that's a rather extreme task for a seldom-used case - if you absolutely have to have the library back in its original state (I'm not even sure the exact reason why you need everything fully reset), you should reload it. ------------------------ Matthew W Fuesz Software Engineer Asc Lockheed Martin STS ------------------ Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6719#6719 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
