Modules exporting functions and objects at the same time.

[vitoco]

Which of these is the best development approach?

1. Write all the functionality of a module as objects, then write and export functions that internally creates an object and calls it's methods.
2. Write all the exportable and internal functions or subroutines, then write code for an object and all the required methods as an interphase to the functions.

I'm thinking in the case of a brand new module, written from scratch, not a group of subroutines taken from personal libraries and put together in a .pm.

Thanks!

PD: Shouldn't this be posted in Meditations?

[roboticus]

vitoco:

Nope. If you have functions that work on various objects, then create them that way. If you have class functions that don't require an object, just make them functions in the package. If you have functions that don't have anything to do with the class and/or objects, then put them somewhere else.

# foo.pm
package foo;

# class variables (not object instance variables)
our %defaults = (bar=>0, foo=>7);

# a couple typical object methods
sub initialize {
    my $this = shift;
    $this->{instance_variable} = $defaults{bar};
}

sub status {
    my $this = shift;
    return $this->{instance_variable};
}

# a class method
sub set_default_bar {
   $defaults{bar} = shift;
}

# etc...

use foo;
my $frob = foo::new();
foo::set_default_bar(2);
my $nitz = foo::new();

print "FROB=", $frob->status(), "\n";
print "NITZ=", $nitz->status(), "\n";

Untested, yadda, yadda, yadda.

...roboticus

[SuicideJunkie]

This is a question, rather than an answer or insight, so SoPW makes sense.

I would say; write the guts of the module however it makes the most sense based on the nature of the problem at hand and the skill of the coder.

One big catch is that if your user makes multiple instances of your object, then the underlying functions need to take care to ensure they are able to handle the different object contexts being thrown around. In general, I would expect it to be easier to start with objects on the bottom, and then add a functional interface which uses a sort of "default" package-scoped object internally.

[ikegami]

So you only have one instance of the object? That's known as a singleton.

You could also create a static class.

package StaticClass;

my $attrib = '...';

# print StaticClass->method();
sub method {
    my ($class) = @_;
    return $attrib;
}

1;

But I like returning an object since it provides a nice upgrade path.

package SingletonClass;

my $singleton;

sub new {
    return $singleton ||= bless({
        attrib => '...',
    });
}

# print $obj->method();
sub method {
    my ($self) = @_;
    return $self->{attrib};
}

1;

Shouldn't this be posted in Meditations?

It's a question, so SoPW is definitely appropriate. I don't mind seeing questions meant to illicit discussion in Meditations, though. Both sections are appropriate for some posts.

[bluescreen]

I'd say that if you gonna use objects use them all the way down, meaning that an class (aka package) must be an self contained UNIT of behavior of your domain model, not a bunch-of-methods-with-no-relation-to-each-other grouped together.

Systems become real hard to maintain, read and refactor when people do not respect objects responsibilities.