| Name : perl-Class-Factory
| |
| Version : 1.06
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : lp155.1.1
| Date : 2023-07-20 18:41:06
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Class-Factory-1.06-lp155.1.1.src.rpm
|
| Size : 0.04 MB
| |
| Packager : https://www_suse_com/
| |
| Summary : Base class for dynamic factory classes
|
Description :
This is a simple module that factory classes can use to generate new types
of objects on the fly, providing a consistent interface to common groups of
objects.
Factory classes are used when you have different implementations for the
same set of tasks but may not know in advance what implementations you will
be using. Configuration files are a good example of this. There are four
basic operations you would want to do with any configuration: read the file
in, lookup a value, set a value, write the file out. There are also many
different types of configuration files, and you may want users to be able
to provide an implementation for their own home-grown configuration format.
With a factory class this is easy. To create the factory class, just
subclass \'Class::Factory\' and create an interface for your configuration
serializer. \'Class::Factory\' even provides a simple constructor for you.
Here\'s a sample interface and our two built-in configuration types:
package My::ConfigFactory;
use strict;
use base qw( Class::Factory );
sub read { die \"Define read() in implementation\" }
sub write { die \"Define write() in implementation\" }
sub get { die \"Define get() in implementation\" }
sub set { die \"Define set() in implementation\" }
__PACKAGE__->add_factory_type( ini => \'My::IniReader\' );
__PACKAGE__->add_factory_type( perl => \'My::PerlReader\' );
1;
And then users can add their own subclasses:
package My::CustomConfig;
use strict;
use base qw( My::ConfigFactory );
sub init {
my ( $self, $filename, $params ) = AATT_;
if ( $params->{base_url} ) {
$self->read_from_web( join( \'/\', $params->{base_url}, $filename ) );
}
else {
$self->read( $filename );
}
return $self;
}
sub read { ... implementation to read a file ... }
sub write { ... implementation to write a file ... }
sub get { ... implementation to get a value ... }
sub set { ... implementation to set a value ... }
sub read_from_web { ... implementation to read via http ... }
My::ConfigFactory->add_factory_type( \'mytype\' => __PACKAGE__ );
1;
(You may not wish to make your factory the same as your interface, but this
is an abbreviated example.)
So now users can use the custom configuration with something like:
use strict;
use My::ConfigFactory;
use My::CustomConfig; # this adds the factory type \'custom\'...
my $config = My::ConfigFactory->new( \'custom\', \'myconf.dat\' );
print \"Configuration is a: \", ref( $config ), \"\
\";
Which prints:
Configuration is a My::CustomConfig
And they can even add their own:
My::ConfigFactory->register_factory_type( \'newtype\' => \'My::New::ConfigReader\' );
This might not seem like a very big win, and for small standalone
applications probably isn\'t. But when you develop large applications the
\'(add|register)_factory_type()\' step will almost certainly be done at
application initialization time, hidden away from the eyes of the
application developer. That developer will only know that she can access
the different object types as if they are part of the system.
As you see in the example above implementation for subclasses is very
simple -- just add \'Class::Factory\' to your inheritance tree and you are
done.
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-C/15.5/noarch |
