Re: Multiple NSTableView question
Re: Multiple NSTableView question
- Subject: Re: Multiple NSTableView question
- From: Phillip Mills <email@hidden>
- Date: Thu, 21 Jun 2001 11:56:11 -0400
On 6/21/01 10:58 AM, "David P. Henderson" <email@hidden> wrote:
>
On Thursday, June 21, 2001, at 09:24 , 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?
>
>
>
>
>
Why? At some point you still have to make the determination of with
>
which table view you are working.
No, that's my point; the different objects should be responsible for the
behavior that defines their differences. Switches (or serial if statements)
that dispatch to different behaviors are warning signs of procedural
programming with an object facade.
>
And using a subclass to do so is
>
complete overkill, better to use conditional testing to make the
>
determination.
Practically, that's a reasonable compromise for simple cases, which is why I
included the phrase, "if doSpecialStuff was at all complex." But, like
accessor methods for members, a little "overkill" can be a really good habit
to develop.