• OOP design choices

    From Luc@luc@sep.invalid to comp.lang.tcl on Sun Sep 29 10:12:32 2024
    From Newsgroup: comp.lang.tcl

    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


    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Rich@rich@example.invalid to comp.lang.tcl on Sun Sep 29 16:29:24 2024
    From Newsgroup: comp.lang.tcl

    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.
    --- Synchronet 3.20a-Linux NewsLink 1.114