You can accomplish this using some pretty basic OO patterns. You want
your client to be ignorant of the implementation of the module with
which it is talking (except to say that it will conform to a particular
interface). Also, you may want to client to be ignorant of the which
module to create an instance of.
The design of objects that conform to a particular interface can be done
by using inheritance. See perlboot and perltoot.
Once the above objects are implemented, you can use a factory pattern to
create the one that the client talks to. The factory knows which one to
create. A factory usually has a make() interface that might look like
something like this for you (this would be your control.pl)
package ObjectFactory;
make()
{
my $host = `hostname`;
my $controlServer = lookupInDatabase($host);
return http-$controlServer->new();
}
-----Original Message-----
From: Roger C Haslock [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 23, 2001 3:49 PM
To: [EMAIL PROTECTED]
Subject: Multiple implementations of an interface
Hi
I am seeking advice of a general nature.
I plan to write some software which will interface with another piece of
software which may have various alternative replacements - for example,
an
http server.
I intend to write a generic interface module, say 'httpd.pm', and use
that
to mask the actual implementations, say 'http-apache.pm', 'http-xyz.pm'.
Presuming that what I propose is poossible, I would appreciate advice as
to
the best way of going about this.
To make the requirement more definite, supose I wish to run a script
'control.pl' on each server machine in a network 'control.pl' uses
'httpd.pm'. The control.pl script, or 'httpd.pm', will find that it is
running on hostname Merlot, and (by database lookup or otherwise) that
the
server for Merlot is type 'frolix': it will then initialise 'httpd.pm'
to
use 'http-frolix.pm'.
How do I cause httpd to use http-frolix, or whatever may be the case? I
have
seen some imaginative use of a 'do' clause, but I thought this was
archaic.
(I expect to write for perl 5.6.x, and hope to reimplement in perl 6
with as
little effort as can be planned. I do not expect the software to be run
on
an earlier generation of perl)
Thanks
- Roger -
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
