Maybe you want to have different implementations or want to replace some parts, while still having a defined sequence of calls.
Personally, I've always run up to the limits of such frameworks, but I can well imagine an ETL task that is basically:
package ETL::Import; sub run( $class, $input_file, $table ) { my $payload = $class->convert_to_csv( $input_file ); $class->cleanup( $payload ); $class->load( $payload, $input_file, $table ); $class->verify( $payload, $table ); };
... and then having
package ETL::Import::CSV; ... package ETL::Import::Fixed; ...
... where each class only overrides (say) ->convert_to_csv and/or ->cleanup.
As I said, I've almost always wanted to change just a tiny bit in the sequence of the call order, or maintain just one bit more information, so I prefer to have the logic of ->run in the main program instead of having it in some superclass. But if ->run is the result of a refactoring where it has proven flexible enough already, I can see how that could work out.
In reply to Re^3: Rename a Moo constructor from "new" to "run"
by Corion
in thread Rename a Moo constructor from "new" to "run"
by nysus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |