Re: Multiple NSTableView question
Re: Multiple NSTableView question
- Subject: Re: Multiple NSTableView question
- From: Brian Hill <email@hidden>
- Date: Thu, 21 Jun 2001 10:07:33 -0500
On Thursday, June 21, 2001, at 08:24 AM, Phillip Mills wrote:
Being new to Obj-C and Cocoa....
This seems very non-OOP and I wonder whether it's a normal Obj-C
idiom. (?)
I would have expected something like:
- (int)numberOfRowsInTableView:(NSTableView *)theTableView
{
[theTableView doSpecialStuff];
[self doCommonStuff];
}
But this, of course, requires extensions to NSTableView...sub-class,
category...? Using PowerPlant, I would have automatically considered
sub-classing (because it's really easy) if doSpecialStuff was at all
complex. Is polymorphism for UI classes abnormal here?
If you really wanted to subclass the table view and do it the way you're
used to, you easily can.
However, from a Model/View/Controller point of view, I'd ask yourself,
'What is the 'special stuff' that needs to be done? Is it in the realm
of the table view (ie., does it have solely to do with presenting the
data in the table), or is it more in the realm of the data model (ie.,
preparing the data so you can count the rows, etc...).
Speaking as a former PowerPlant programmer myself, I used to have dozens
of subclasses of LTableView to do various specialized things, but with
Cocoa I find that it's better for me to only subclass user interface
widgets when I really need to have the widget act or look differently on
screen.
The delegate/datasource structure that Cocoa has (and PP doesn't) allows
me to use the same table view classes to present widely different types
of data. The 'data-specific' logic stays in controller and data model
classes.
In fact, I'd gotten to the point in my own PowerPlant programming where
I was creating a set of classes very similar to the 'data source' idea
when I started Cocoa programming, since I had gotten tired of having to
create a new subclass of LTableView each time I needed to display a
different sort of data.
In general, Cocoa makes far greater use of aggregation/delegation than
PowerPlant does, and I've found that it helps keep the MVC separation
intact as opposed to subclassing UI widgets for specific purposes.
About polymorphism and UI classes in Cocoa -- yes, it's all over the
place - in fact, since (generalization coming...) classes in ObjC are
sort of defined by the messages they respond to more than their
'ancestry' (at least in comparison to C++), there is a lot more
'informal polymorphism' in Cocoa than in PowerPlant.
For example, consider the TableDataSource informal protocol itself. You
don't need to specify that your data source multiply-inherits from some
abstract 'TableDataSource' protocol -- you just implement the methods
you need, and the table view asks it's data source which of these
methods have been implemented at run time.
Brian
email@hidden
http://personalpages.tds.net/~brian_hill
___________________________________________________________
"Why? I came into this game for adventure - go anywhere, travel
light, get in, get out, wherever there's trouble, a man alone.
Now they've got the whole country sectioned off and you can't
move without a form. I'm the last of a breed."
-- Archibald "Harry" Tuttle, Rogue HVAC Repairman
___________________________________________________________