Discipulus has asked for the wisdom of the Perl Monks concerning the following question:
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?
L*
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: subclassing: how to design my module
by stevieb (Canon) on Feb 09, 2018 at 15:11 UTC | |
Re: subclassing: how to design my module
by Anonymous Monk on Feb 11, 2018 at 03:14 UTC |