Cocoa mail archive
Re: Cocoa coding style with multiple NSTableViews in a NSApplication
FROM : Alberto Ricart
DATE : Thu Dec 23 19:29:33 2004
The patterns are there as a guide. They make code/methods usually
smaller at the cost of additional objects - objects are code
organization. This translates into simpler maintenance, and less bugs.
As to what you can do, you can do whatever you want.
Bindings are cool, but you are replacing one kind of programming with
another. Maybe you don't write the code (a good thing), but then you
have to dig in nib files to find out what the thing is doing. Obviously
there are many choices.
From the original question, the issue was whether to implement on
object that proxies both models or several. For that the answer is
several, because it is both simpler and easier to maintain.
/a
On Dec 22, 2004, at 6:22 PM, Scott Stevenson wrote:
>
> On Dec 22, 2004, at 3:34 PM, Alberto Ricart wrote:
>
>> The Uber/UniModel (or any other OO code) peppered if/else/switch
>> statements is not very OO. While it does work fine for simple things,
>> if quickly fails when changes creep in, and it provides increased
>> opportunity for bugs. Then you'll be adding chunks of
>> if/else/switch/etc making the code harder to read as the code grows.
>> In short this is an actual "smell" for OO code that cries to be
>> replaced by inheritance/or sibling classes sharing something/or
>> nothing.
>
> This is just opinion (there's no one right answer), but using
> inheritance or multiple classes in these situations is
> over-engineering the problem. Object-oriented texts may encourage an
> approach like this, but Cocoa tends to frown upon it because it ads
> the complexity of additional classes without real value.
>
> Chances are good that a single window will never have more than 3
> table views in. You have, at worst, a three-part if statement. That's
> much less code to maintain and compile than three separate classes.
> Additional windows should get their own window controller.
>
> The purest Cocoa thing you can do here is use bindings, which will
> also help you avoid running into a bug with Panther table views that I
> posted about a ways back.
>
>
> - Scott
>
> --
> http://treehouseideas.com/
> http://theocacao.com/ [blog]
>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
>
DATE : Thu Dec 23 19:29:33 2004
The patterns are there as a guide. They make code/methods usually
smaller at the cost of additional objects - objects are code
organization. This translates into simpler maintenance, and less bugs.
As to what you can do, you can do whatever you want.
Bindings are cool, but you are replacing one kind of programming with
another. Maybe you don't write the code (a good thing), but then you
have to dig in nib files to find out what the thing is doing. Obviously
there are many choices.
From the original question, the issue was whether to implement on
object that proxies both models or several. For that the answer is
several, because it is both simpler and easier to maintain.
/a
On Dec 22, 2004, at 6:22 PM, Scott Stevenson wrote:
>
> On Dec 22, 2004, at 3:34 PM, Alberto Ricart wrote:
>
>> The Uber/UniModel (or any other OO code) peppered if/else/switch
>> statements is not very OO. While it does work fine for simple things,
>> if quickly fails when changes creep in, and it provides increased
>> opportunity for bugs. Then you'll be adding chunks of
>> if/else/switch/etc making the code harder to read as the code grows.
>> In short this is an actual "smell" for OO code that cries to be
>> replaced by inheritance/or sibling classes sharing something/or
>> nothing.
>
> This is just opinion (there's no one right answer), but using
> inheritance or multiple classes in these situations is
> over-engineering the problem. Object-oriented texts may encourage an
> approach like this, but Cocoa tends to frown upon it because it ads
> the complexity of additional classes without real value.
>
> Chances are good that a single window will never have more than 3
> table views in. You have, at worst, a three-part if statement. That's
> much less code to maintain and compile than three separate classes.
> Additional windows should get their own window controller.
>
> The purest Cocoa thing you can do here is use bindings, which will
> also help you avoid running into a bug with Panther table views that I
> posted about a ways back.
>
>
> - Scott
>
> --
> http://treehouseideas.com/
> http://theocacao.com/ [blog]
>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
>
