in reply to Re^2: Factory classes in Perl (updated)
in thread Factory classes in Perl
because different "missing" modules have different interfaces !
The factory creates objects/classes with the same interface (which might themselves make use of a specialized CPAN module under the hood ... or not)
Example: you create something with a complicated dynamic table, with rows and cells.
Tables with rows and cells are a universal concept, but the details differ a lot.
The factory could produce output-backends for
but all now with the same interface for geometry, color, font, etc.
And just supporting the features you really need for the problem at hand.
The code for the complicated table is just using the factory and doesn't need to care about the output details.
And if someone needs to target new media - like a fancy JS-library for grids - you'll just add an implementation to the factory.
I don't know if that's even possible (or how useful the feasable may be), but it's an example.
Now take a look at all the modules for Tables and ask yourself how you'd write reusable code to use multiple of them.
Part of the problem here is that most of the literature for factory classes will be written with JAVA like languages in mind. Perl is far more TIMTOWTDI.
In Perl I could imagine a factory "package" without any OOP involved.
Or a factory "function" (aka a generator) to create functions. (generators are actually quite common in functional programming but rarely as complex as packages)
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery