On 12/06/2013 10:01 PM, Greg London wrote:
then the code to do stuff is generic across ALL the register types.
Wouldn't I get that with polymorphism?
If every class had randomValidDate()
and each method handled the different
internal data format, don't I get a
"generic" interface for all register types?
it isn't exactly polymorphism but i am sure you could map one to the
other. to break it down, each register has a data structure (could be a
simple hash or more complex). these structures are well defined and
contain attributes or constants or even code references. there is a sub
(or set of subs) that processes that structure for that register. if it
finds an attribute it will call the appropriate sub or method. it may
call a code ref it finds. it may use some data it finds. the idea is to
map the range of needs you have to simple data and code that uses that
to handle all the variations you need. the polymorphism aspect is that
the data structure is designed to have many variants of similar things.
I'm not familiar with this "table driving" approach.
is there a >>short<< example on the web I could look at?
check out the testing code for Sort::Maker on cpan. it uses a table to
set up tests including a golden sort code (a code ref), input data,
expected output data, expected error, etc. there is a driver module that
reads and processes the array of structures. each attribute of a test
(which are optional) is handled by some code in the driver sub. in that
design there is only a single sub doing all the possible work. in your
case you may have some set of small worker subs doing specific things
that many different registers need. a driver sub can look at the
structure you created for a register and decide which worker subs to
call, what to pass to them, what to expect, etc.
File::Slurp also does this and it has a t/TestDriver.pm. several of tits
.t test scripts use it. the sort module's driver is called t/common.pm
and it is used by all the .t scripts.
table driven logic is very easy to code up, easy to add things too and
extremely easy to make many variants. you can start small (simple
structure and short driver code) and incrementally add stuff as you go.
making variants is just copying an existing structure and changing
something. when you look at the tables in those tests you can see how
variants were added.
thanx,
uri
--
Uri Guttman - The Perl Hunter
The Best Perl Jobs, The Best Perl Hackers
http://PerlHunter.com
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
