http://qs321.pair.com?node_id=11115287


in reply to Re^4: Override new in Moose for flyweight objects
in thread Override new in Moose for flyweight objects

The main motivation is not to save one keystroke (that just ends up happening because "_" is one keystroke fewer than "::"). The main motivation is dependency injection. When you do MyApp::Widget->new() you are hard-coding the class name. Hard-coding is code smell. There are many Perl programmers who would agree that hard-coding is bad, but don't even think of using class names like that as hard-coding. But it is hard-coding and it makes your code less adaptable. The idea in Zydeco is instead of doing MyApp::Widget->new(), you do $self->FACTORY->new_widget(). Now the widget class isn't hard-coded, and if you need to use a different widget class (such as a mock widget for your test suite) you can just wrap new_widget.

package MyApp {
  use Zydeco declare => [qw(TestingRole)];
  
  my $testing = true;
  
  role TestingRole {
    ...;
  }
  
  class Widget {
    ...;
  }
  
  if ($testing) {
    around new_widget (@args) {
      my $widget = $self->$next(@args);
      Moo::Role->apply_roles_to_object($widget, TestingRole->role);
      return $widget;
    }
  }
}

my $factory = 'MyApp';

print $factory->new_widget, "\n";

[download]

(Note that the declare bit it only so we can declare TestingRole as a bareword for use later on. In general you don't need to declare the existence of roles and classes beforehand.)

toby döt ink

Replies are listed 'Best First'.
Re^6: Override new in Moose for flyweight objects
by Tanktalus (Canon) on Apr 10, 2020 at 02:14 UTC

    I think we're getting far afield of the original topic, but that's okay, this is way more interesting than Stackoverflow's format :)

    I've been more or less forced into the C# world these last couple of years, where dependency injection isn't just a technique, but a way of life. And I've been less than impressed by the alleged improvements this is supposed to make when done the C# way. For the most part, I've managed to reject it. There are places where it's useful, but I've yet to be convinced on many other places. And there are places where it's downright harmful. But I digress.

    Now, I'm assuming your hardcoded $testing would normally be done via some other method, whether environment variable or some other global variable, it's just here this way for example. With that, you just wrapped around MyApp::new_widget so that you could change its behaviour. I'm curious, though, why you couldn't just wrap around MyApp::Widget::new instead. Which, truth be told, is pretty much what I have done in the past. And once even in production (not test) code. Without Moose or any other similar framework (again, didn't exist). When done in production, it's called monkey patching. When done in test, it's called mocking :)

    Now, I'm not arguing that you should change all your code, I'm just not convinced that there's really any benefit to bucking convention. If you're creating a Foo, then it should be Foo->new. If that's a traditional factory underneath, doesn't really matter, practically speaking, as it was always a factory anyway. And if a particular constructor needs to temporarily be replaced with a different one, well, you can always replace it, even just temporarily. (Hey, if you can hawk your modules, so can I :-D )

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom