Thread from comp.lang.tcl (1 reply)

I am rewriting my application which has tabs.

Now I hesitate. Which is better?

1. Create the overall GUI and code as procedural and the tabs as 
objects/a class.

2. Create the overall GUI as a big object (superclass) with tabs as 
subclasses.

3. Create the overall GUI as an object/class with tabs as separate
classes.

4. Create the overall GUI as a big object (superclass) with tabs as 
methods.

Thank you for any ideas.


-- 
Luc
>>

Luc <luc@sep.invalid> wrote:
> I am rewriting my application which has tabs.
> 
> Now I hesitate. Which is better?
> 
> 1. Create the overall GUI and code as procedural and the tabs as 
> objects/a class.

If by "has tabs" you are referring to the project you posted about here 
some months ago, then this layout (with each tab being backed by an 
object) would be most similar to what you have now.  Your 'namespaces' 
per tab were becoming very "home-made object" like as you progressed.

> 2. Create the overall GUI as a big object (superclass) with tabs as 
> subclasses.

Here I suspect you may be getting confused by the implementation detail 
in TclOO that classes are themselves 'objects'.  While TclOO would 
allow you to use the 'superclass' itself as an object for the overall 
GUI, such usage is not the typical usage of classes/superclasses.  The 
class/superclass concept is traditionally used to create a templating 
system for creating the end objects that are used by the code.  A class 
groups together all the common aspects (variables/methods) of a set of 
objects (i.e., that mammals all have hair) so you can define the 
commonality once, and then use the template (the class) to stamp out 
objects that differ only in things specific to that object (i.e., that 
one has blue eyes, the other brown eyes).  Superclasses then are 
typically used to stamp out similar classes by grouping all the 
commonality into one place, and then each stamped out class is tweaked 
just a little for the small difference it has from other classes 
stamped out from that superclass.

> 3. Create the overall GUI as an object/class with tabs as separate
> classes.

This is also another way, although the conventional description would 
be the GUI as one object, and each tab as its own object.

But do you have gui aspects that are independent of each tab?  If yes, 
then this (or #1) would be a somewhat conventional design, provided you 
used objects for the tabs rather than TclOO classes.  You can have a 
'class' that holds all the common aspects of a tab, but you'd stamp out 
an object from the class to be the backing handler of a given tab.

> 4. Create the overall GUI as a big object (superclass) with tabs as 
> methods.

Not really object oriented in the conventional sense.  This is simply 
taking your existing procedural code, wrapping it in a thin veil of 
"OO" and calling the result "OO".  This just gives you OO in name only 
with everything simply being procedural inside.