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);
}

[download]
and in SNMPMonitor::Plugin::Atest define 
sub plugin_oid_val { '1.2.5' }

[download]
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)

Replies are listed 'Best First'.
Re^2: Inherited Object Constructor Question
by PyrexKidd (Monk) on Sep 11, 2011 at 23:49 UTC

    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?

[reply]
      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;

      [download]

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

      package My::Project::SomeClass;

use Moose;

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

...

1;

      [download]

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

      Improve your skills with Modern Perl: the free book.

[reply]
[d/l]
[select]
      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).

[reply]

In Section Seekers of Perl Wisdom