Re: Singleton as a common area?
Re: Singleton as a common area?
- Subject: Re: Singleton as a common area?
- From: Graham <email@hidden>
- Date: Thu, 21 Feb 2008 09:59:34 +1100
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.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden