Moose design question

elTriberium has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

I have a question about designing Moose classes: I have a module A which has multiple features B, C, D, because multiple people will work on these and it would be nice to have this logical separation of the different features. The features B, C, D need to have access to A themselves (they run something on A).

I want to put A, B, C, D, ... into different files.

The user should only have to instantiate A and then use the other classes through it, such as:

my $a = A->new();
$a->b->method();
$a->c->another_method();
[download]

A simple way to make this work would be:

package A;
has b => ( isa => 'B' );
has c => ( isa => 'C' );
sub BUILD {
    my ($self) = @_;
    $self->b(B->new(a => $self));
    $self->c(C->new(a => $self));
}

package B;
has a => ( isa => 'A', required => 1);
sub method { 
   my ($self) = @_;
   $self->a->exec(...); # Stuff related to B
}

package C;
has a => ( isa => 'A', required => 1);
sub another_method {
    my ($self) = @_;
    $self->a->exec(...); # Stuff related to C
}
[download]

But this solution doesn't seem to be very 'clean' apart from that it does what it should. It's not making use of any OO concepts, it's just hardcoding the different classes together.

I'm not very familiar with Moose Roles, could I use those to achieve the desired behavior?

Comment on Moose design question Select or Download Code

Replies are listed 'Best First'.
Re: Moose design question by moritz (Cardinal) on May 19, 2011 at 19:22 UTC
I have a module A which has multiple features B, C, D, because multiple people will work on these and it would be nice to have this logical separation of the different features. That's not the way you should design object-oriented code. You should find useful abstractions based on how they interact with each other, not by who develops them. It's not making use of any OO concepts That might be an indicator that you don't actually need any OO - how about just a hash with objects B, C, D? Or a sub that returns those objects, based on the argument you pass to it? The existence of shiny OO tools don't mean you have to use them for every case. What doesn't your current solution do that you might want from it? Extensibility? You can still stick other objects in the attributes if you make them writable (a hash provides that by default). `sub another_method { my ($self) = @_; $self->a->exec(...); # Stuff related to C }` [download] Looks like delegation would make your life easier here. But in general it is very hard to give advise based on such general descriptions. It could be anything from "Don't use OO at all" to "use delegation" or "use roles" or "stick with your current approach" - we just don't have enough context to decide. Perl 6 - second systems done right	[reply] [d/l]
Re^2: Moose design question by elTriberium (Friar) on May 19, 2011 at 20:18 UTC
Thanks for you answer. You should find useful abstractions based on how they interact with each other, not by who develops them. I agree, this was not a good example. But as I mentioned these modules are logically separated, so I wanted to introduce the abstraction in the class design. Looks like delegation would make your life easier here. Thanks for that tip and also to John M. Dlugosz for mentioning delegation, too. I have not looked into this before, will definitely do that now.	[reply]
Re: Moose design question by John M. Dlugosz (Monsignor) on May 19, 2011 at 19:22 UTC
Delegation. I found it interesting that this let me easily move around which helper class or which of a set of collaborating classes actually implemented the thing. B and C contain references to the A parent, and the 'has' 'handles' construct can specify to delegate all the functions that A is providing. Likewise, the variable in A that holds its B also delegates functions that B implements. Methods in either class can just refer to functions in the overall complex, and not care which object is handling it. If you move a function, you change the 'has' lines but no other code! This is inside what you are calling B: `has tag_formatter => ( is => 'ro', handles => [ qw( format_tag escape filter link_prefixes)], required => 1, weak_ref => 1, # normally points back to parent Creole object ); has config_keeper => ( is => 'ro', handles => [ qw( placeholder_callback link_mapper image_mapper)], required => 1, weak_ref => 1, # normally points back to parent Creole object );` [download] Both of those are pointing back to A. But I could further break up A and make the tag formatter into yet another separate class later! —John	[reply] [d/l]
Re: Moose design question by TomDLux (Vicar) on May 22, 2011 at 05:52 UTC
When you're driving a car, do you reach through the dashboard and angle the front wheels slightly to the right? No, you use the control components of the car, namely the steering wheel. It has some sort of relation to the front wheels, but you don't know if that's a mechanical linkage, a power-assisted linkage, or a drive-by-wire arrangement. In the same way, your A should provide the user interface; any additional modules it uses in the implementation should be hidden from the user. In real life, things are not always totally hidden, after all, you have to inflate tires, replace a flat tire, check the oil ... but routine operation is through components available to the driver seat. As Occam said: Entia non sunt multiplicanda praeter necessitatem.	[reply]


Do you know where your variables are?
	PerlMonks