Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
Re^3: Factory classes in Perlby LanX (Saint) |
on Jan 12, 2021 at 00:04 UTC ( [id://11126771]=note: print w/replies, xml ) | Need Help?? |
> ...and thought - "why not just install the missing module then?" 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.
UPDATEPart 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)
Cheers Rolf
In Section
Seekers of Perl Wisdom
|
|