Re: is protected broken, or am I?
Re: is protected broken, or am I?
- Subject: Re: is protected broken, or am I?
- From: Andy Lee <email@hidden>
- Date: Thu, 10 Oct 2002 19:22:21 -0400
At 3:42 PM -0700 10/10/02, matt neuburg wrote:
There is a bunch of code in MyClass, and there are a lot of
connections set up between the MyClass instance and the window in
the nib (represented by the double-headed arrow). Now I have a bunch
of *other* code that governs this *other* behavior of the *same*
window. The question is, where shall I put this code?
I don't want to put it into MyClass because MyClass is already huge,
and also because this will mean that just about every method in
MyClass will be a huge if/then statement doing one thing on one set
of occasions and another thing on another set of occasions.
This sounds like a great candidate for using a delegate. Delegates
are a technique for switching the behavior of an existing object at
runtime.
Isolate those behaviors that depend on whether you are in Situation A
or Situation B. Instead of having MyClass perform those behaviors
directly, add a myDelegate instance variable to MyClass and call
methods of myDelegate to perform those behaviors. Pass arguments as
necessary to the myDelegate methods so it gets whatever information
it needs about MyClass without having to poke directly into its ivars.
You can then have instances of two different delegate classes, a
MyClassDelegate and a MyOtherClassDelegate. At runtime, you can use
-setMyDelegate: to switch between these delegates depending on
whether you are in Situation A or Situation B.
That is just the sort of the problem that classes are supposed to
solve. Instead of if/then, you just supply a different class, and
the right thing happens because whichever class the message is sent
to an instance of, it contains the right code.
The reason your case is different from the usual "subclasses just do
the right thing" case is that you want an *existing* instance of a
class to start behaving as if it were an instance of a different
class. This is not generally possible in Objective-C -- well, unless
you want to start hacking a class's IMPs at a low (and dangerous)
level.
Much better to use the delegate paradigm. Delegates are why we
rarely have to subclass NSTextView or NSWindow or NSApplication.
They are also why we in Cocoa-land don't miss multiple inheritance
terribly much. In fact, delegates are *more* flexible than multiple
inheritance because they allow behavior to change at runtime.
--Andy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.