Singleton as a common area?
-
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.
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.
This generally means that I have lots of source files.
It seems to me that a singleton object could be used
to hold lots of global state info and it would be
easy to instantiate the singleton in each of the
source files to access the stashed info...
Is this a reasonable way to share info?
Thanks,
Jerry -
On Feb 20, 2008, at 7:16 PM, Jerry LeVan wrote:
> 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.
>
> This generally means that I have lots of source files.
<nit-picking>
You don't "build objects", you design classes. While you end up with
"lots of source files", your implied question should be "is it OK to
end up with a lot of classes" and the answer to that is: YES.
> It seems to me that a singleton object could be used
> to hold lots of global state info and it would be
> easy to instantiate the singleton in each of the
> source files to access the stashed info...
<nit-picking>
Similarly, you don't apply the singleton pattern to a source file, but
to a class.
> Is this a reasonable way to share info?
The singleton pattern is very useful, and I think it's reasonable to
end up with a lot of your classes being singletons.
j o a r -
On Feb 20, 2008, at 12:04 PM, Jerry LeVan wrote:
> It seems to me that a singleton object could be used
> to hold lots of global state info and it would be
> easy to instantiate the singleton in each of the
> source files to access the stashed info...
>
> Is this a reasonable way to share info?
Sometimes you just create a single instance of a class.
Other times you enforce that only zero instances or one instance can
ever be created. To do this second thing,
http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaObjects/chapter_3_section_10.html
Then you can use your singleton,
#import "Foo.h"
[Foo sharedFoo];
which is nice because now you don't have to keep track of instances
of Foo. You just get THE instance right from the class method.
The documentation above explains when this is a good way to do things.
James -
On Wed, Feb 20, 2008 at 9:03 PM, James Hober <jhober...> wrote:
>
> On Feb 20, 2008, at 12:04 PM, Jerry LeVan wrote:
>
>> It seems to me that a singleton object could be used
>> to hold lots of global state info and it would be
>> easy to instantiate the singleton in each of the
>> source files to access the stashed info...
>>
>
>> Is this a reasonable way to share info?
>
> Sometimes you just create a single instance of a class.
>
> Other times you enforce that only zero instances or one instance can
> ever be created. To do this second thing,
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/
> CocoaFundamentals/CocoaObjects/chapter_3_section_10.html
>
...and if you don't want to re-implement that for each of your
singletons, FTSWAbstractSingleton is a nice starting point -
http://www.cocoadev.com/index.pl?FTSWAbstractSingleton -
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. -
On Feb 20, 2008, at 11:59 PM, Graham wrote:
>> 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.
Well, there's that - BUT - In OOP you typically want to create
components with as few dependencies as possible on surrounding code,
this often makes it easy to prototype your new components outside of
the project where they will eventually be used. Doing it this way can
have many advantages:
- Turnaround time is typically faster, as a small sample app
typically has much less overhead
- Your new component starts out in a clean environment with fewer
unexpected side effects
- You're encouraged to not create unnecessary dependencies on other
components in your main project
Granted, most of the time I write new code in the main project, but
using a sample project is also a powerful tool to be used from time to
time.
j o a r
