in reply to object oriented module question

Inheritance is one option, but you could also use delegation. Create a Text::CSV object, and store it inside your own object. You can then access that object to perform the actions you need. 
package My::Module;

use Text::CSV;

sub new {
    my $class = shift;
    my $self = {
        _text_csv => Text::CSV->new( ... ),  # we store the object her
+e
    };

    bless $self, $class;
}

sub some_method {
    my $self = shift;

    # we use it here
    my $result = $self->{_text_csv}->some_text_csv_action( @input );
}

[download]

Replies are listed 'Best First'.
Re^2: object oriented module question
by exussum0 (Vicar) on Sep 07, 2007 at 11:44 UTC
    Note: Not advisable you create the object w/i the only, paramaterless constructor.

    Should you wish to use something-else as the CSV parser or want to do some other stuff (such as testing) w/o requiring Text::CSV about, now you're stuck.

    If anything, create a function/method and feed it in. p.s. I know it is only an example.

[reply]
      I'd say I do this (object blessed into my object) pretty routinely and it hasn't bitten me yet. I use this primarily when I want to use the functionality of an object within my object without really extending the existing object.

      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?

[reply]
        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.
[reply]
[d/l]
        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).
[reply]
Re^2: object oriented module question
by Anonymous Monk on Sep 07, 2007 at 05:15 UTC
    For a good example, check out the source code for Parse::CSV It does pretty much exactly what the previous commentor is describing. (full disclosure, I wrote it)
[reply]
      full disclosure, I wrote it
      None needed, you're anonymous ;)

      -David

[reply]

In Section Seekers of Perl Wisdom