I suspect what you’re looking for is a helper class which your parent class accesses via a HASA or USES relationship. But in the absence of concrete details it’s hard to give more definite advice.

Yes, that is essentially what I'm trying to do.

Specifically, I'm working on an API for Samba 4 Active Directory using Net::LDAP. The API is meant to abstract much of the LDAP code needed to query the AD. For example, you could ask the api:

And then the API would spit out the requested data. The problem I was running into is that the over all perl module was getting large in size, so I thought I'd try and spin off some of the methods to sub-classes. Good examples are those methods associated with users would get a module: Users.pm. And then those associated with groups, Groups.pm.

So my module structure looks like this:

The methods in Users.pm and Groups.pm really do specialize active directory objects generated in the parent module. Following your example, a user ISA object.

So the primary reason for wanting the parent class to see the child class methods, we me being lazy, I think.

Lazy Code (child method called from parent constructor):

use esmith::AD;
use strict;

my $ad=esmith::AD->new();

warn "User exists\n" if ($ad->doesUserExist('greg'));


Proper code (child method called from child constructor):

use esmith::AD::User;
use strict;

my $ad=esmith::AD::User->new();

warn "User exists\n" if ($ad->doesUserExist('greg'));
[download]

Hello gzartman,

Thanks for adding the <code> tags to the OP.

If you really need do need to call doesUserExist() from the parent class (which I doubt), you’ll have to give the parent class a default version of this method, then override it in the child class(es) as needed. For example (untested):

package esmith::AD;

sub doesUserExist
{
    return 0;           # default answer: 'No'
}

package esmith::AD::User;

use List::Util qw( any );

my @user_names;         # class variable

sub doesUserExist
{
    my ($self) = @_;    # assuming that $self is a hash reference

    return any { $_ eq $self->{Name} } @user_names;
}
[download]

But I still don’t see what you gain by this. In your example, the “lazy” code is no shorter than the “proper” code, so why not just use the latter?

It occurs to me that you might, just possibly, be looking for some form of factory, but again this seems like overkill unless you have a good reason for it?

Update: The test for whether or not a new user already exists should, of course, be done in the constructor.

Hope that helps,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

Anthanasius,

Thank you for the reply and good info. This is making quite alot more sense to me now. I've been using perl for years, but more for system calls and what not, like one would use shell.

I see now where I was looking at the sub-classes backwards. I've got a really good book titled "Advanced Perl Programming" by Sriram Srinivasan. I spent the day reading through this and reflecting on your comments.

My ultimate goal is this a easy to use Active Directory API that abstracts Net::LDAP, which I think I've done a fairly good job at doing from a OOP standpoint. I was just looking at the sub-classes incorrectly. I'm rethinking my design now so that the sub-class methods properly inherit functionality from the parent class. One of the things I want to be able to do is to have methods in my parent class that do things like listing Active Directory objects, by object type (i.e., DNS, Users, Groups). I then would have methods in my child class that would be called directly to list the type of objects you are after, causing the method in the parent class to morph to list the requested AD objects called by the method in the child class. I think I'm now there.

Not the OP, but, Why is this backwards? This is actually a design pattern that I use somewhat regularly with Moose. Or the Correlary, Moose makes this design pattern extremely easy to implement with Delegation (and it's more advanced cousin Currying)

An example is my Build::VM library I'm working on: https://github.com/three18ti/Build-VM/blob/master/lib/Build/VM.pm

In my main class Build::VM, I have (stripped down):

package Build::VM;
use 5.010;
use Moose;
use strict;
use warnings;

use Build::VM::Guest;

has guest       => (
    isa         => 'Build::VM::Guest',
    lazy        => 1,
    default     => sub {
        Build::VM::Guest->new(
            name    => $_[0]->guest_name,
            memory  => $_[0]->to_kib($_[0]->guest_memory),
            disk_list   => $_[0]->disk_list,
            cdrom_list  => $_[0]->cdrom_list || [[]],
        );
    },
    handles    => {
        get_memory => 'memory',
    }, 
);
[download]

Then in my driver script that calls the module, I do:

#!/usr/bin/perl
use 5.010;
use strict;
use warnings;

use Build::VM;

# Get the parameters from the CLI or config file

my $bvm = Build::VM->new( 
    name => $name, 
    memory => $memory, 
    disk_list => $disk_list, 
    cdrom_list => $cdrom_list 
);

say $bvm->get_memory();
[download]

(ok, bad example because cdrom_list is the only one that is using delegation, technically ->memory is a method in the Build::VM::Guest object, it's just not a user defined function so it's a little more ambiguous).

Unless I'm misunderstanding what OP wants to do, why is this backwards or inside out? And if it's so backwards, why does Moose make it so easy? If you don't mind, what would be the appropriate organization for my various modules?

Also, when talking about Perl and inheritance, (which is what I think of when I hear "child class") I'm usually pointed to Moose Roles because they make multiple inheritance trivial (because it's not really inheritance, it's more like Ruby's mixins).

Thanks, I always like posts like this, even though it's not something I thought I was doing wrong, I like to learn when I am :)

-three18ti

Some food for thought

my $ad = AD->new( $server, $login, $pass );

if( my $user = $ad->GetUser( 'craig' ) ){
    $user->replace( company => 'rompany' );
    $user->company( 'rompany' );
} else {
   $ad->AddUser(
       company => 'rompany',
   );
}


sub AD::new {  ... return $conn }
sub AD::GetUser {
    my( $conn, $user ) = @_;
    return AD::User->get( conn => $conn, user => $user );
}
sub AD::AddUser {
    my $conn = shift;
    Add::User->add(  conn => $conn, @_ );
}

sub AD::GetGroup {
    my( $conn, $group ) = @_;
    return AD::Group->get( conn => $conn, user => $group );
}

sub AD::User::add {
    ... croak "name cannot be 42";
}
[download]

More food for thought App::LDAP, Net::LDAP::Class, Catalyst::Model::LDAP