Discussion:
OOP design choices
(too old to reply)
Luc
2024-09-29 13:12:32 UTC
Permalink
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
Rich
2024-09-29 16:29:24 UTC
Permalink
Post by Luc
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.
Post by Luc
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.
Post by Luc
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.
Post by Luc
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.

Loading...