To add an example, I have a toy project Filesys::DB, and there are various maintenance operations for the database:
First I also had these within the scripts implementing these operations. Then I moved them into Filesys/DB.pm, and now I have Filesys/DB/Operation.pm, in which these operations live. In the longer run, the operations will likely move into their own sub-files.
As an example, moving a method from the main class into another module/class can be done like this with Moo:
# Old version package My::Example; use 5.020; use Moo 2; use experimental 'signatures'; sub do_foo( $self, %options ) { ... }
# New version version package My::Example; use 5.020; use Moo 2; use experimental 'signatures'; has 'operation_foo' => ( is => 'lazy', default => sub { My::Example::Operation::Foo->new(), }, handles => ['do_foo'], ); package My::Example::Operation::Foo; use 5.020; use Moo 2; use experimental 'signatures'; sub do_foo( $self, %options ) { .... }
Using objects for holding code mostly makes sense if the operations don't really need information that lives in the "parent" class.
Update: choroba spotted a misspelled does where it should have been handles.
In reply to Re^3: multiple inheritance alternative(s)?
by Corion
in thread multiple inheritance alternative(s)?
by Danny
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |