Re: Multiple NSTableView question
Re: Multiple NSTableView question
- Subject: Re: Multiple NSTableView question
- From: Glen Simmons <email@hidden>
- Date: Thu, 21 Jun 2001 13:24:54 -0500
The encapsulation that you want is already there. The NSTableView knows
which object is its dataSource, but by pointing multiple TableViews at
the same object, I think you are defeating the encapsulation. This is
analogous to having multiple data objects "encapsulating" one big pile
of data and then internally having to figure out which piece of the pile
is theirs.
As a previous poster suggested, use different objects as the dataSource
for the different tables. Then there's no if / switch to worry about.
Glen
On Thursday, June 21, 2001, at 11:13 AM, Phillip Mills wrote:
On 6/21/01 11:07 AM, "Brian Hill" <email@hidden> wrote:
On Thursday, June 21, 2001, at 08:24 AM, Phillip Mills wrote:
- (int)numberOfRowsInTableView:(NSTableView *)theTableView
{
[theTableView doSpecialStuff];
[self doCommonStuff];
}
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...).
I agree completely. It touches on the idea of whether objects should be
designed based on behavior. If so, then the polymorphic approach makes
more
sense to me because it expresses the idea that the difference between
the
objects is *in* the objects.
Setting up the logic with multiple "if" statements expresses the idea
that
the objects don't encapsulate their differences, but rather are
differentiated by what some other object does to/with them.
Perhaps it's just a question of whether one is more comfortable with a
particular style.
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.
This gets close to what I was almost asking. :-) Assuming that I want
to
keep making objects that are responsible for all (or most of) their own
behavior, what's the "more Cocoa than sub-classing" way of getting
there?
Specifically, what kind of a things (categories? protocols?) do I
create to
implement the various "doSpecialStuff" methods of my above example?
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev