TclOO：如何从fruit类中获取其创建的orange类实例对象

First off, your current implementation is totally valid and aligns with basic OOP principles—you're encapsulating the internal orange object state behind a method, which is exactly what good encapsulation calls for. But let's explore a couple of other idiomatic approaches that might fit different design goals:

1. Refined Encapsulation with Explicit Component Access #

Your existing approach can be polished to make intent clearer, following Tcl OO's conventions. We can also add proper cleanup to avoid orphaned objects, which is a common OOP best practice:

namespace eval test {}
oo::class create test::orange {
    constructor {}
    destructor {
        puts "[self] destroy..."
    }
}

oo::class create test::fruit {
    constructor {type} {
        if {$type eq "orange"} {
            my variable orangeObj
            set orangeObj [test::orange new]
        }
    }
    method getOrange {} {
        my variable orangeObj
        # Handle edge case where no orange was created
        return [expr {[info exists orangeObj] ? $orangeObj : ""}]
    }
    destructor {
        my variable orangeObj
        # Clean up the nested orange object when fruit is destroyed
        if {[info exists orangeObj]} {
            $orangeObj destroy
        }
        puts "[self] destroy..."
    }
}

set f [test::fruit new "orange"]
set orangeFromFruit [$f getOrange]

This emphasizes that orangeObj is part of the fruit object's internal state, and we provide a clear, named method to access it. The destructor addition ensures we don't leave unused orange objects hanging around.

2. Factory Pattern (Shift Responsibility to a Factory) #

If your test::fruit class is primarily meant to create specific fruit instances (like orange), a factory pattern might be a better fit. Instead of instantiating a fruit object that contains an orange, have fruit act as a factory that returns the appropriate fruit type directly:

namespace eval test {}
oo::class create test::orange {
    constructor {}
    destructor {
        puts "[self] destroy..."
    }
}

oo::class create test::fruit {
    # Make constructor private to enforce factory usage
    constructor {} {error "Use test::fruit create instead"}
    # Factory class method to create specific fruit objects
    classmethod create {type} {
        switch $type {
            "orange" {return [test::orange new]}
            # Add other fruit type cases here later
            default {error "Unknown fruit type: $type"}
        }
    }
}

# Get the orange directly from the factory
set orange [test::fruit create "orange"]

This follows the single responsibility principle: the fruit class now only handles creating correct fruit objects, rather than acting as a container for another object. Perfect if you don't actually need a fruit instance—you just need the specific fruit type.

3. Composition with Delegation (For Shared Behavior) #

If your test::fruit is supposed to share behavior with the orange it creates, you can use delegation. This lets the fruit object pass method calls to the internal orange automatically:

namespace eval test {}
oo::class create test::orange {
    constructor {}
    destructor {
        puts "[self] destroy..."
    }
    method eat {} {
        puts "Eating an orange!"
    }
}

oo::class create test::fruit {
    constructor {type} {
        if {$type eq "orange"} {
            my variable component
            set component [test::orange new]
            # Delegate all unknown methods to the nested orange object
            oo::objdefine self forward my {*}[info object methods $component]
        }
    }
    method getComponent {} {
        my variable component
        return [expr {[info exists component] ? $component : ""}]
    }
    destructor {
        my variable component
        if {[info exists component]} {
            $component destroy
        }
        puts "[self] destroy..."
    }
}

set f [test::fruit new "orange"]
$f eat ;# This automatically calls the orange's eat method
set orangeFromFruit [$f getComponent]

This is great if you want the fruit object to act as a wrapper that exposes the orange's functionality directly, while keeping the orange as an internal component.

Which One Should You Use? #

• Stick with your original approach (refined as in option 1) if you need a fruit object that contains an orange as part of its state.
• Use the factory pattern (option 2) if fruit is just a tool to create specific fruit instances and you don't need the fruit object itself.
• Use delegation (option 3) if you want the fruit to share the orange's behavior without relying on inheritance.

All these approaches follow OOP best practices like encapsulation, single responsibility, and clear interface design.

内容的提问来源于stack exchange，提问作者Mkn