good chemistry is complicated,
and a little bit messy -LW
Re^3: Perl Modules -- abstraction and interfacesby Discipulus (Monsignor)
|on Jun 20, 2017 at 22:20 UTC||Need Help??|
your thread is long and somehow confusing, but here you say something that captured my attention:
> many that interact together and require each other in circus
First some firm stone, to not let confusion overhelm us: Some::Module must be in Some/Module.pm and this path must be in @INC or added to it at runtime using -I perl switch. See perlmod (and perlrun for the perl switch). Also notice that you (i think is not a constrain but more a convention) you start Some::Module declaring a package with the same name package Some::Module; ( PS read tobyink's wise advices in Re: Module's name and file's name )
Second: the easy way is to use Exporter; and fill @EXPORT_OK with every sub you want to be usable (with use ..) by other programs or modules. All sub you put in @EXPORT will be exported by default, generally not what you want.
After this basic level abstraction will be the keyword. I have a little experience but when I ended with a tools.pm module as a an unorderd collection of subs i know i was on the looser path.
For such reason choosing rigth names(spaces) for your modules is so hard, generally harder than choosing sub names. They reflect how you approached the problem/subject you'll resolve with you programs. In more complex cases you can have entire trees of modules with the deeper ones specializing the parent: like Project::Display will be responsable to compose messages to be shown and Project::Display::Console and Project::Display::HTML will handle differnt display types.
Nothing bad if Project::Logger uses a facility sub you defined in Project::Display .If you are always sure where you put your subs and you export the sub correctly everybody is happy.
Once a wise programmer said "progrimming is a matter of interfaces" and is true. A lot true. If your module just exposes a mixed collection of beahviours this will no matter a lot. But when you find that some subs in your module are, and possibly must remain, private to such module, you are implicitly thinking an interface.
Consider having a Project::Postman that is used to send out mails: the module can just expose one or few subs but can have dozen of private subs to check mail addresses, availability of smtp servers.. Less you expose and as much as this remain stable, more you will be able to change internally Project::Postman without braking any program that uses, consumes your module.
More you stress this in your programs more you tend to just expose one sigle sub that return a scalar, or an object if you want, that is autosufficient and knows who it is and what behaviour to put in the field.
As much will be easy for you to do such name/functionality abstraction, as much you'll be closer to Object Oriented programming, easy to realize using Perl, with or without OO frameworks.
As always you have a lot of different options you must follow your inclination or needs of particular projects.
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.