in reply to Re: OOP: Plugin Style Development
in thread OOP: Plugin Style Development

Here's where the windows OOP brainwashing kicks in for me:

package Display::LDAP;

@ISA = qw(Display::Base);

sub new
sub foo
sub bar

[download]

If I was the one making the LDAP module, no problems. But what if someone else is doing it? What bugs me is that if I decide to start using Display::Foo instead of Display::LDAP, there's no way to know if Display::Foo is going to play nice, or ignorant for that matter.

I was just looking at Class::Contract, but that's overkill for now

Not to mention, if Display::LDAP overrides all the methods that Display::Base exports, then why use Display::Base at all? I've seen modules whos 'public' subs call private "_" subs inherited form the base class. But that's just like any other method, you can't assume anything about the overloaded base class. If it decides not to call the private methods from base, game's off anyways.

Replies are listed 'Best First'.
Use sane Design (was Re3: OOP: Plugin Style Development)
by dragonchild (Archbishop) on Jul 22, 2002 at 19:58 UTC
    There is a very good reason to use a base class. This way, you can do something like: 
    die "This isn't a Display adapter!"
    unless $display->isa('Display::Base');

$display->doSomething(@args);

    [download]

    As for your concern about contracts and enforced APIs ... Perl doesn't do that. You're just going to have to make sure with all other developers that everyone agrees on an API.

    IMHO, this is a "Good Thing"(tm). More communication between developers is good.

    You can do a few things in the base class to provide for interface checking. Here's a canonical way to implemental a virtual function: 

    sub foo {
    my $self = shift;

    die "Whoever wrote '", ref($self), "' is a dork. S/He didn't overr
+ide foo()!";
}

    [download]
    Then, when a client expects foo() to be a method and it isn't overriden, you can take a "Clue-By-Four"(tm) to the offending author. (Something along the lines of "Why didn't you follow the agreed-upon spec?!?" Of course, you need one of those to have a leg to stand on .........)

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
[d/l]
[select]

      *smacks forehead repeatedly*

      I always forget the little things, repeat after me, can() and isa() are your friends. :-P

      The more it sinks in, the more I think I like the following approach: public subs (mysub) in Base that call private subs (_mysub).

      When a module uses and overrides base, it should override the private subs. This gives me enough of a warm fuzzy about preserving the public methods signature (if only in theory).

      Is there anything wrong with this approach from the standpoint of painting myself into a corner?

      Thanks for the help, and the patience.

[reply]
        That works. It seems a little heavy-handed, but I can see no issues with it in my 3 seconds of comtemplation. :-)

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]

In Section Seekers of Perl Wisdom