Still don't get it...

Post #148,732 by Arkadiy 3/26/04 8:29:03 AM Reply	Still don't get it... How is a class a reference to object? Static member can be... -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #148,738 by Arkadiy 3/26/04 9:15:38 AM Reply	I guess now I do Garbage-collecting class - what a stupid idea! As long as there is a single line of code that can possibly reference them, those things cannot be collected. GC that only counts references from stack is G. -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #148,766 by tuberculosis 3/26/04 10:49:01 AM 8/21/07 6:12:12 AM Reply	Think singleton instances reference class - makes sense, in singleton a static references the single instance. Nice circular package that nothing else is referencing for awhile - so it gets GC'd. Way dumb. Java is a joke, only it's not funny. --Alan Lovejoy Edited by tuberculosis Aug. 21, 2007, 06:12:12 AM EDT Expand All History
Post #148,768 by deSitter 3/26/04 10:59:11 AM Reply	Translate into non comp-sci jargon? -drl
Post #148,808 by tuberculosis 3/26/04 1:59:46 PM 8/21/07 6:12:42 AM Reply	Singleton is a pattern Consider where you think you have an object that represents a single thing. Like the keyboard. You have two options - you can make all the methods to deal with the keyboard class methods. After all there is only one and what sense does it make to have programmers allocating Keyboards willy nilly? So you make all the methods class methods and the class object itself represents THE keyboard. This sounds great - until USB arrives and you want to write a two player game letting each player have his own keyboard. Now you've got potentially several keyboards and the keyboard class you wrote is junk - you can't use it. So we hedge our bets - we actually create a keyboard class but put all the behavior on the instance side. Then we make the class responsible for determining how many keyboards there can be and what the allocation policy is. For conventional single keyboard apps you implement singleton. There is exactly one instance of the Keyboard and you ask the class for it. In Java this looks like this: public class Keyboard { // make the constructor private - only the class can call it private Keyboard() { ... } // keep a copy of the singleton static _instance; // provide a way to get the singleton - construct only if asked for public static instance() { if(null == _instance) _instance = new Keyboard(); return _instance; } ... } When you get to your game, you only have to tweak the class a little like: private Keyboard { Keyboard _player1(); Keyboard _player2(); public static Keyboard player1() { if(null == _player1) blah blah blah } you get the idea. You use the class to control how many instances of a class exist. The problem I alluded to is that - with the class instance variable being the only reference to the object, and the object being the only reference to the class, the GC concluded nobody else would care if the thing went away. This is basically true - but one win to singletons is you initialize them once and they sit there all warmed up and ready to use. Collecting the class caused a lot of thrashing of initialization code. Stupid Java people. Java is a joke, only it's not funny. --Alan Lovejoy Edited by tuberculosis Aug. 21, 2007, 06:12:42 AM EDT Expand All History
Post #148,812 by ben_tilly 3/26/04 2:06:14 PM Reply	Translation Sometimes you want an expensive to compute thing to be available in many places. A standard way to do it is to create a class that will only produce one object. If you call the class' constructor, it will produce and save the object only if it doesn't exist, then return it. On the second call it just returns it. This is called a singleton because there is a single instance of the class. The problem is that when one person has used the singleton you have an object that exists which isn't referenced outside the class. A good GC algorithm would detect that the object is still in use and shouldn't be destroyed. In real software, the object can get detected as garbage and destroyed, forcing you to create it again. Not desired since not having to create it again and again was, after all, the point of creating singleton. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]

Welcome to IWETHEY!