Not if the delegates are already subclassed from classes not sharing a
common ancestor. Even if they have a common ancestor, I might not have
access to the source code for the ancestor so I might not be able to
refactor the common code to that level. The end result is having to
repeat code in several classes.
On Jul 25, 2009, at 11:46 PM, Luke the Hiesterman wrote:
That approach makes much more sense.
Luke
On Jul 25, 2009, at 2:44 PM, Kyle Sluder wrote:
On Sat, Jul 25, 2009 at 1:14 PM, WT<jrca...@gmail.com> wrote:
This particular text field needs to limit its number of characters
to a
given interval. Why should any other object have to deal with that
problem
when the field itself can take care of it? Still, it might be the
case,
though it also might not be the case, that another object wants to
participate in the editing session. The flow of events here is as
follows:
the field takes care of its own business first (limiting the
number of
characters) and then allows the delegate, if any, to have its shot
at the
editing process.
In the Cocoa world, it makes more sense to hook up a delegate to do
this work, especially if this is a one-off control. It comes down to
thinking of it as "a text field which limits number of characters"
rather than "a number-of-characters-limited text field". If you need
this behavior in multiple places in your application, you can factor
out the delegate behavior into a superclass and have your delegates
derive from it, calling this method when necessary.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
