I agree this is a bad example to use polymorphism in but you might as well try it.
First, I need an abstract method. Is it just sub foo {}; or sub foo; or what? Or should I leave the declaration away altogether?
I usually croak in abstract methods, in hopes they are always overloaded.
sub process_input { croak "Cannot use an abstract method; }
Second, but most important, now that the switch is gone, how do I go about from user input $foo to a certain subclass foo method? Drawing a blank here.
You can maybe use a Factory design pattern, or have a sub choose the object. This is basically another switch statement :P. Or maybe you can use a dispatch table like the one shown above.
Third, sharing code between B and C is more difficult. Formerly, when everything was in one package, I just had a sub for the common code. How do I handle that now that they are in different classes?
Hmmm.. you could have C be a subclass of B...
In reply to Re: replace conditionals with polymorphism
by juster
in thread replace conditionals with polymorphism
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |