Re: Shared objects and other data
Re: Shared objects and other data
- Subject: Re: Shared objects and other data
- From: Andy Lee <email@hidden>
- Date: Tue, 2 Apr 2002 11:25:18 -0500
At 11:08 PM -0500 4/1/02, email@hidden wrote:
What is the best way to implement an instance of a class so that it is
available to all applications that request the shared object?
The wording here makes me hesitate. If you really mean "all
applications," a solution using Distributed Objects might indeed make
sense, as others have suggested. Or, depending on the requirements
of your application, it might make more sense to make it
AppleScript-aware, so that other applications don't see the instance
per se, but can still ask it to do things via AppleScript commands.
Similarly, a client-server design might be more appropriate. Or
Cocoa Services, if the object only needs to be available to
applications running on the same machine as your application.
Would it be
best to make this a static global object in the source file for the class
which is instantiated upon initializing the class with a class method?
Doing this wouldn't make the shared object visible to other
applications, only to other objects in your application. So I'm
going to assume the latter is what you meant to ask.
A variable declared as "static" in your class's .m file will have
global lifetime. When you assign it a value, that value stays put
between method calls. This is just C. It's not terribly
object-oriented, but it's the only way in Objective-C for variables
to have global lifetime. We don't have "class variables" or "static
members" like some other languages (which themselves vary in how O-O
they are in this respect).
Suppose your .m file declares a static variable like this (for
simplicity, let's say outside of any method):
static MyClass* _sharedInstance = nil;
Although it has global lifetime, this variable's *scope* is limited
to the .m file. You can't refer to it directly in any other code.
To provide access to the variable's value outside of the .m file, you
can give your class an accessor method like this (remembering to
declare it in your .h file):
+ (MyClass *)sharedInstance
{
return _sharedInstance;
}
Then there is the question of when to initialize the static variable.
Depending on your requirements, you may indeed want to set it in your
class's +initialize method, or you might want to modify the getter as
follows:
+ (MyClass *)sharedInstance
{
if (_sharedInstance == nil)
{
_sharedInstance = [[MyClass alloc] init]; // or whatever
}
return _sharedInstance;
}
Also,
how should data that is used in several methods be dealt with; should such
data be declared as static global in the source file for the class, or is
there a more OOP style for doing this?
I prefer to avoid the term "global," because it can mean either
global in *scope* or global in *lifetime*, and the two meanings are
sometimes confused. That said...
Yes, one way of sharing data between methods is to declare static
variables in your .m file (note that a class typically has *two*
source files, the .h interface and the .m implementation). One
method X can assign values to the static variables, and later another
method Y can pick up those values. There is some risk associated
with this, as you want to be sure the values haven't been corrupted
before method Y gets to them, especially in a multi-threaded app or
even in a single-threaded app with any type of recursion. Also note
that this approach shares the data not only between methods, but
between all the *instances* of your class, which you may or may not
want.
A variation on this would be to declare instance variables whose only
purpose is to cache these values between method calls. This is ugly,
but might not be so ugly if upon reflection you find that these
values are really properly classified as attributes of the class.
Yet another option that may or may not be appropriate in your case is
to define a struct or a lightweight class that contains the shared
data, and to pass a pointer to it as an argument to certain methods.
This can also be ugly; you probably don't want anybody outside of
your class to know about the struct.
I would think about why you have so much non-instance-variable data
that is to be shared between methods in the first place. Maybe there
is a way to redesign your class so you don't have this awkwardness,
just by altering its semantics, or by reorganizing your methods.
HTH,
--Andy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.