Ah, Singleton, my poor Singleton, of all patterns the GoF identified you must feel the most battered and bruised -- used more often than any other in all manner of places where you don't fit. Singleton is appropriate wherever there is a fundamental reason why you cannot or should not have more than one copy of an object. Is there any fundamental reason why you cannot or should not have more than one Data? Well, to the contrary, I'd say. Steer well clear. - Peter
Peter that was very poetic. You should write more books.
The muse suddenly came to me, and I thought I could extend Peter's poetry a little (inspired by Shakespeare, Peter, and the article "When is a Singleton Not a Singleton?" at http://developer.java.sun.com/developer/technicalArticles/Programming/singletons/#resources): The Singleton, -- to use or not to use? The grace of pattern overwhelms me, -- You've been the subject of abuse, Or so the ranch sheriffs try to tell me The heat of virtual hot spot machine Make all my initializers lazy But class loaders are really mean, -- They make two instances, amazing! And then the garbage man comes in To claim the memory unreferenced And when I call it from the bean It's doubleton, as if I had no preferance! The call to get an instance comes along, But quickly gets preemted by someone to blame. I now have a tripleton, and I am prone To crashes, errors, tears, and paine. Eugene Kononov.
what about the DataAccessFactroy. would that not be a candidate for a Singleton ? that one factroy object can handle any pooling of DataAccess objects ?
Actually what would be the problem of having a thousand DataAccessFactory(s) in the client, I could take any one of them call the "Make" method to make by Object, and be sure that I could use it without any worries. Now of course in my coding I am not going to create more than one instance of the DataAccessFactory, but that is me coding, I don't need the Singleton Pattern to save me in any way shape or form in this case Mark Oh, and Eugene you're right on. "The Quality of Singleton Pattern is not strain.."
Singleton is appropriate wherever there is a fundamental reason why you cannot or should not have more than one copy of an object. Is there any fundamental reason why you cannot or should not have more than one Data? Well, to the contrary, I'd say.
In my implementation I'm using two static factory methods in Data.java: one called open, the other called create. These methods use a HashMap that contains previously created instances of class Data, keyed by a File object representing the file containing the database. This scheme ensures that only one instance of class Data exists per file within a single JVM. This is of course a variant of the Singleton pattern, and one which I think applies to Data. What do you think? -- Jason Voegele
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com