Re: ObjC in time-critical parts of the code
Re: ObjC in time-critical parts of the code
- Subject: Re: ObjC in time-critical parts of the code
- From: Justin Carlson <email@hidden>
- Date: Sun, 18 Jan 2009 19:13:24 -0600
Jean-Daniel Dupas wrote:
> > An additional problem is that it does not scale well. Programs
mature,
> > objects are used beyond their initial intent, programmers come
and go
> > and that source becomes a nightmare to maintain. Getting back to
good
> > OO style, why take the messaging overhead (how often do your
subclasses
> > rewrite getters/setters?)
>
> Each time you use KVC/KVO.
Hi Jean-Daniel,
Sorry if I misreading this, your response was short - it could mean a
few things. I am inclined to think you were responding to my question
"how often do your subclasses rewrite getters/setters?".
The point that I was trying to make was that accessors are _generally_
not implemented by the subclass, but by the class which declares them
(at least, as I write them).
I would generally write:
- (void)setMovie:(MyMovie *)newMovie {
// make sure it is ok here
// actually change the instance variable here (do retain/release
dance, etc.)
// If by interface, call a designated update method which subclasses
may implement, such as [self movieChanged]. You could also use use KVO
for this.
}
- (MyMovie *)movie {
// make sure it is ok here
// actually return the instance variable (do retain/autorelease dance
if applicable, etc.)
}
This allows the accessors to be straightforward (a good thing,
considering the amount of redundance), and subclasses could then
implement [MyMoviePlayer movieChanged] for their custom interpretation
of the object's implementation. Of course, there is no need to signal
(i.e. call movieChanged) for every ivar, or to provide a unique call
for every ivar. Back to the point that I was trying to make: Some
people generally put their objects' *real* implementation in the
accessors, but that is not generally a good design (again, IMO) since
it is difficult to maintain complex class hierarchies - even if you
call super's implementation through the class which declared the ivar.
In most cases, it is easiest to maintain classes with minimal
accessors, which signal a change (where applicable), rather than 3
subclasses later, implementing the accessor. It keeps code small and
focused. In C++, that would be rephrased as: "How often do your
accessors need to be virtual?".
J
_______________________________________________
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