Re: Inherited Object Constructor Question

[Arunbear]

in reply to Inherited Object Constructor Question

In SNMPMonitor you can define set_oid as

sub set_oid {
    my $self = shift;
    $self->plugin_oid($self->plugin_oid_val);
}

and in SNMPMonitor::Plugin::Atest define

sub plugin_oid_val { '1.2.5' }

Then you should get the desired behaviour.

BTW why not use Moose for this? For the purpose of reuse, it seems cleaner to provide set_oid via a role, since a Plugin doesn't seem like a convincing subtype of a SNMPMonitor (e.g. Liskov substitution principle)

[PyrexKidd]

This solution is so simple, I had to laugh out loud. My co-worker thought I was nuts until I showed him your reply. It wasn't immediately obvious, but having seen the solution it is a definite /facepalm moment.

To answer your question, I'm not using Moose because I hadn't considered it, this is primarily due to my lack of understanding of Moose. Looking at the module for Moose::Manual::Roles I can see what you are saying, but I'm not if it becomes more clear. As a sysadmin the majority of my programming is functional, I'm relatively new to OO Perl and OO Design.
I guess my biggest issue is I am not sure how to load my "plugins" with moose.

As far as naming goes, how is SNMPMonitor::Plugin::MySQL_Monitor not a subclass of SNMPMonitor? (I grant you ATest is not really a subclass of anything, but I don't use Foo::Bar for testing by default). That is, each Plugin will have its own methods that are independent of each other, but they will eventually a return a value to the engine (test.pl, due to be renamed).
That being said, perhaps it would be more clear if all of the constructors and similar methods were in SNMPMonitor/Plugin.pm? since SNMPMonitor represents the entire SNMPMoitor framework?

[chromatic]

I guess my biggest issue is I am not sure how to load my "plugins" with moose.

I use Module::Pluggable::Object:

package My::Project::HasPlugins;

use MooseX::Role::Parameterized;

parameter 'namespaces', isa => 'ArrayRef', required => 1;

role
{
    my $p          = shift;
    my $namespaces = $p->namespaces;

    has 'plugins', is => 'ro', isa => 'ArrayRef', lazy_build => 1;

    method _build_plugins => sub
    {
        return
        [
            Module::Pluggable::Object->new(
                instantiate => 'new',
                search_path => $namespaces,
            )->plugins
        ];
    };
}

1;

... and in a class which needs to use plugins:

package My::Project::SomeClass;

use Moose;

with 'My::Project::HasPlugins'
    { namespaces  => [ 'Some::Plugin::Namespace' ] };

...

1;

You can do this without the parametric role, but it worked really well for my project.

[Arunbear]

If you replaced an instance of SNMPMonitor with an instance of SNMPMonitor::Plugin::MySQL_Monitor, would your program still run correctly? If not, then the latter should not be a subclass of the former (which is what the Liskov Substitution Principle says).

Yes it would be clearer to have methods common to all plugins in a base plugin (or role).