Re: Customizing controls: Inheritance bad?
Re: Customizing controls: Inheritance bad?
- Subject: Re: Customizing controls: Inheritance bad?
- From: Negm-Awad Amin <email@hidden>
- Date: Fri, 31 Oct 2008 09:49:30 +0100
Am Do,30.10.2008 um 16:51 schrieb Brian Williams:
Hello,
I'm brand new to Cocoa/Obj-C and I'm working on converting an app. to
use Cocoa...
I've heard that, in general, if you are using inheritance in Cocoa,
you're not following the typical standard design pattern. Is this
true?
To respond to special keyboard events in an NSTableView, I created a
subclass and provided an implementation for keyDown.
To draw some customized stuff in an NSColorWell, I created a subclass
and provided an implementation for drawRect.
Etc.
In the olden days, this kind of object-oriented approach was perfectly
correct.
But I'm told I should be using delegate methods and firstResponders
somehow.
In general, is there a preferred approach to using actions over
delegates, and delegates over handling Cocoa events? It seems there
are
many different ways to handle the same problem and some ways are
preferred over others...
Typically you inherit a class to implement some specialized work. The
problem you get is called white-boxing, because a subclass gets very
much information, which should be encapsulated inside the class. So
inheritance is a little bit "dangerous".
Many cocoa classes gives you the chance to specialize the behaviour of
their instances by delegating. A delegate is an extern instance. So it
is black-boxing instead of white-boxing. You still have an API
contract. This is the better design.
So *if* you can do your work using a delegate, in many cases you
should prefer this way.
However, some classes are intended for derive them, i. e.
NSWindowController. There is nothing wrong doing so, if it is
intended. Read the subclassing notes for the class in the
documentation. And have a look to the delegate methods.
Cheers
Also, could someone recommend a good intro to FirstResponders as
this is
a concept I don't understand fully yet?
Thanks,
Brian
_______________________________________________
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
Amin Negm-Awad
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