Re: Singleton as a common area?

FROM : Graham
DATE : Wed Feb 20 23:59:34 2008

Hi Jerry,


On 21/02/2008, at 5:16 AM, Jerry LeVan wrote:

> It is probably due to my meager design skills, but more
> than once I have wished that I could have easy access to
> objects from other objects.


You can, trivially. myState = [someOtherObject state];

> I have a tendency to build an object and fiddle with it
> and when I understand  how it works, I have to ease the
> rascal into the main application.


Not wishing to cause offence, but this sounds bass-ackwards. You 
design a class to solve a stated, defined problem. You don't start 
with an "empty" object (for want of a better term) and stuff random 
functionality into it until it does something useful. OO design is 
just as easy to abuse as the older traditional programming models and 
will lead to nasty spaghetti-like designs just as easily. If you 
aren't clear what problem it is you are trying to solve this is where 
the effort should be spent.

None of us are perfect in this respect but classes should have well-
delineated functional boundaries. If you find yourself stashing 
miscellaneous functions into a class just out of convenience it's 
probably indicative of a poor design or a lack of understanding of 
what you're trying to accomplish. Taken to its logical conclusion any 
application would only have one instance of one class that did 
everything. Which is equivalent to the non-object-oriented model of 
programming.

OO design comes more naturally to some than others. These days I find 
it very natural but I recall when I started (with MacApp), coming 
from a traditional approach, I found it really hard going at first. 
Some good books on general OO design could well help you, as they did 
me. Others might be able to recommend something. Also look at lots of 
sample code and study Cocoa itself - really "getting" OO often comes 
simply through observation and will suddenly click.


> This generally means that I have lots of source files.


Lots of source files is not, in and of itself, a problem. Most non-
trivial projects end up having hundreds if not thousands of source 
files. This is what makes projects manageable. However one should try 
to minimise dependencies between them as far as possible.

> It seems to me that a singleton object could be used
> to hold lots of global state info


It could.

> and it would be
> easy to instantiate the singleton in each of the
> source files to access the stashed info...


This sounds contradictory. If it's a singleton, then by definition 
it's not instantiated in more than one place, or conversely, if it's 
instantiated more than once, it's not a singleton.

However, I think what you mean is that you can access the singleton 
instance from anywhere that needs the info. In other words it's a 
global variable, like all singletons.


> Is this a reasonable way to share info?
>


There's no right answer to that. It might be in your situation.

I have to say though that this particular design pattern has very 
rarely cropped up in my projects. Yes, singletons are often useful in 
specific situations but I haven't used them to stash all sorts of 
arbitrary global state data. Normally that state info resides in 
whichever objects are appropriate. Sometimes that might not  even be 
an object - simple static and global variables are occasionally used. 
However a good rule of thumb is to only use globals (and singletons 
are globals) as a last resort because they create pathways between 
different parts of the code that are not obvious, which can lead to 
bugs that are hard to find. You can reduce this with singletons by 
making them non-mutable by design, so they have that advantage over 
naked globals.

Mechanisms for sharing information between objects include:

a) straightforward references/messages from one object to another

b) delegates

c) NSNotifications

d) KVO

e) invocation forwarding

There are probably others that have temporarily slipped my mind.

HTH,

--------
S.O.S.