|P is for Practical|
subclassing: how to design my moduleby Discipulus (Monsignor)
|on Feb 09, 2018 at 11:08 UTC||Need Help??|
Discipulus has asked for the
wisdom of the Perl Monks concerning the following question:
Greetings nuns and monks,
I'm still wondering how my module should look like: the module was announced here but I just received one comment, a precious one by Anonymous Monk, but in my reply I planned a bit more of abstraction probably worth to be implemented. I ask here, and no to the above mentioned thread, because it seems to me a separate question.
So the actual plan is to have a generalist Win32::Event::Engine module which can trigger any type of action instead of just write to a logfile.
So I plan to separate the event reading part and put it or as a subclass of the above or as a separate module on it's own. Which option seems more appropriate?
Then for the reader module I want to provide a simple wrapper around Win32::EventLog as default and optionally, instead of this, a wrapper around the wevtutil.exe that is difficult to use per se and can access even exotic events registries (as told in the OP too).
Should I create a Win32::EventReader as empty class having two separate modules like Win32::EventReader::EventLog (using the Win32::EventLog already existing module) and Win32::EventReader::Wevtutil (using the warpper around the system call)?
Or Win32::EventReader using by default Win32::EventLog and a subclass Win32::EventReader::Wevtutil ? In this case how to manage the user choice? An option in the constructor that replace the current new call with a subclass one?
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.