It seems to me that whether you make your object inherit from (@ISA) or bless it into an object you'll still need the parent (Text::CSV) anyway. I'm not trying to nitpick, just want to know I understand things correctly. Am I missing something?

exussum0 didn't object to delegation in general, just to the way I did it in my example. And he has a good point too: It's usually better to access the delegated object through an accessor method, because of the arguments he gave, and because it allows lazy loading. In that way, the delegated object is only constructed on first use. It also allows easier overriding.

If I were to rewrite my example using an accessor, it'd look something like this:

package My::Module;

sub new {
    my $class = shift;
    my $self = {};    # no clutter!

    bless $self, $class;
}

sub some_method {
    my $self = shift;

    # we use it here
    my $result = $self->_csv->some_csv_action( @input ); # uses access
+or
}

sub _csv {
    my $self = shift;

    # allow to be set from outside
    if(@_) {
        $self->{_csv} = shift;
    }

    # default to Text::CSV
    if( !defined $self->{_csv} ) {
        require Text::CSV;
        $self->{_csv} = Text::CSV->new( 'some args' );
    }

    return $self->{_csv};
}
[download]

I'm sure that could be refined further, but it demonstrates the basic idea. The benefit should be clear: it's now possible to supply a My::Module object with a different CSV object, which makes testing easier, as well as customizing the behavior of our class.

That is definitely an improvement over the way I've been doing things. Thanks for the code example. Luckily (for them), I'm the only one who has to maintain my code, but that is much cleaner and much more modular.

I have little bit of an idea ... But since I am so new to oo method, let me sit on this and think about it a bit and let you guys know.. But thank you(I will be sure to post on what I find as viable solution for myself).