Re: Communication between objects
Re: Communication between objects
- Subject: Re: Communication between objects
- From: "I. Savant" <email@hidden>
- Date: Wed, 11 Feb 2009 10:56:28 -0500
On Wed, Feb 11, 2009 at 10:42 AM, Jason Wiggins
<email@hidden> wrote:
> I understand MVC ...
Sorry, but I disagree. You've still got some concepts missing. :-)
> Now, I understand I need a pointer to the "other object", but I am failing
> (in a BIG way) in understanding HOW to get it or create it.
> myControllerObject has a pointer to it's children because it knows about it
> because it created it.
In MVC, it's typical for your controllers to be responsible for
creating the model objects. Consider an app that manages a "library"
of things. For simplicity, it's only one kind of thing. The left-hand
pane might be a "source list" style table listing all the objects in
the library. You might call this the "LibraryController". It's
responsible for creating, deleting, reordering, and overall managing
LibraryItem model objects.
By making this the sole responsibility of the LibraryController,
there's always only one place that a LibraryItem instance would be
created. If the LibraryController created it, the LibraryController is
free to set its properties any way it wishes, including "[object2
setOtherObjectYouNeedToKnowAbout:object1];
> But if modelObject1 doesn't know modelObject2 even exists, how can I create
> a pointer to it? Where do I get this reference from?
Never said that. It's quite common for model objects to know about
each other. It's just as common for controllers to know about
one-another. It's just not "right" (according to MVC) for the model
*layer* to know anything about anything in the controller or view
*layers*, even if they're designed to work together.
Consider Core Data. It's an "object graph management and persistence
framework". If we ignore the persistence part (ie, we're not
interested in Core Data's file saving capabilities, only its object
graph management capabilities), we still get a *very good* system for
managing an object model (the schema as well as the actual graph of
object instances that your app creates / manipulates). An Employee
object needs to know about a Department object (and vice-versa)
because they have a relationship. So a Department must have an
-employees property (an array or set) to which Employee instances can
be added or removed (or re-sorted, etc.). Likewise, an Employee must
have a -department property (it's a two-way relationship, after all).
When an employee instance is created, that's the ideal time to set its
-department (or, the other way, when a new department is created,
you'd add employees). Core Data handles this very well (makes it
easy), but without it, you need to enforce that logic yourself.
Still, see my LibraryController points above ... a controller is
responsible for actually manipulating / managing the model.
--
I.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