Re: memory problem with bi-directional referenced objects
Re: memory problem with bi-directional referenced objects
- Subject: Re: memory problem with bi-directional referenced objects
- From: Serge Meynard <email@hidden>
- Date: Fri, 11 Mar 2005 18:07:45 -0500
I have some memory management questions relating two classes of
object that point to eachother.
[snip]
How would you implement such a system with bi-directional
referencing? I have the feeling I am making it more complicated than
it has to be, but right now I am leaking memory ...
Yes, you're making it more complicated than it is. Basically the rule
is to never create loops in your memory code. Look for "Retain
cycles" and "Weak References" in this page:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/
index.html
If you follow this rule in your design, things should become much
simpler to manage. Always make it clear in your mind which object
owns which.
Serge
Thanks Serge,
that makes things a lot clearer. Even gave me the insight that my
formerly produced code was wrong to begin with.
However I have still a question about my design, because I might have
a much bigger (meta) retain cycle at my hands:
I have four classes in a carré. Two controller classes and two view
classes, or, two parent classes and two child classes.
IRController - IRView
| |
IRSegment -(?) IRViewSegment
the IRController has an IBOutlet to IRView and has a NSMutableArray of
IRSegments
the IRView has an IBOutlet to IRController and has a NSMutableArray of
IRViewSegments
Now I want to the IRSegment to know about which IRViewSegment is
representing him and I want each IRViewSegment to know to which
IRSegment they represent.
Should those both references be "weak"?
Thanks,
dirk
As we all know, the devil is in the details. But the structure you
describe is quite common; in fact the app I'm working on now has the
same issues to deal with. This is how I'd approach it.
The IRSegment objects (a model class from the looks of things) clearly
belong to the IRController. The IRViewSegment objects (a view class)
also clearly belong to the IRView. Between the two segment classes, the
link should either be weak both ways, or else the IRViewSegment can
claim ownership of the IRSegment (which doesn't create a loop).
Because the IRSegment is a model class, it should never claim ownership
of a view class; typically you want your model to be as independent as
possible from the view. In fact, if you can manage it, it's probably
best if the IRSegment doesn't know about the IRViewSegment in the first
place. It's always tempting to encapsulate too much behavior in a model
class, especially in a small program; for example having the IRSegment
call an invalidation method in IRViewSegment when its data changes. But
it's usually best to find other ways of doing so. For example, the
controller can take responsibility for informing the corresponding
IRViewSegment whenever it modifies an IRSegment; or the IRSegment can
be modified through a method in IRViewSegment, which then simply
invalidates itself. This type of approach also gives you finer control
over what gets done when, which may help you avoid undesired
side-effects or optimize updates, for instance.
It's up to you to decide how important it is, in the context of your
project, to expend effort to enforce model independance. For a small
and simple application, it may be more trouble than it's worth. But
it's generally a good thing, and your code will be cleaner and less
bug-prone for it.
Serge
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden