Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
- Subject: Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
- From: Ilan Volow <email@hidden>
- Date: Sun, 11 May 2008 00:19:56 -0400
Wouldn't an alternative to a "dirty" property for each object would be
to do a Cocoa version of the Martin Fowler's Unit Of Work pattern (see http://martinfowler.com/eaaCatalog/unitOfWork.html)
and every time there's a change observed that affects the dirty
property, you'd register it as a "dirty" object and throw the object
into the dirty array that belongs to what ever object has been
designated as the observer (and avoid creating an actual dirty
property at all?)
-- Ilan
On May 10, 2008, at 2:40 PM, Jens Alfke wrote:
On 9 May '08, at 7:41 PM, Chris Hanson wrote:
(6) Leverage Cocoa framework features in your own code. For
example, you don't need to have setter methods that invoke -
setDirty:. You can just write a method like this
- (NSSet *)keyPathsForValuesAffectingDirty {
return [NSSet setWithObject:@"UUID"];
}
and then anything that cares about whether a particular object is
dirty can observe its "dirty" property.
But you still need to implement the "dirty" property, with a getter
that returns the corresponding ivar; and the other setters like -
setUUID: need to set the ivar to true.
So what you're describing comes down to just (a) removing -
setDirty:, and (b) replacing the internal calls to it with
"dirty=YES". Is this any simpler or cleaner? It's the same number of
lines of code, and now if you add a new property to the class you
have to remember to add its name to the set in
keyPathsForValuesAffectingDirty. Plus, I'll bet the internal general-
purpose dependency tracking is less efficient than the hardcoded
call to -setDirty.
In addition,
* keyPathsForValuesAffectingDirty should be a class method, not an
instance one
* You didn't point out that this only works on 10.5. On 10.4 it will
compile without warnings but will be ignored at runtime, causing
hard-to-debug wrong behavior when your property dependencies fail to
work.
—Jens_______________________________________________
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
_______________________________________________
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