Re^2: Designing multiple related modules

[Fletch]

Agree with your PS. A factory is the way you hide your implementation classes (quoth c2: "It allows classes to defer object creation to a separate method") from callers who just use that API to obtain the specific flavour they're wanting with something like Bod::Social->new_for( 'Twitter' ) rather than explicitly hardcoding creating an instance of a specific subtype. End users just know they're getting something that isa Bod::Social and can expect it to provide that same interface specialized for their particular kind of thing. You also don't have to go change callers to have them instead instantiate Bod::Social::NewTwitter n months hence when you create a new subclass which is faster or handles some new wrinkle; change the factory and callers get the improved version without knowing they have to ask for it.

Prossibly not germane in this particular case but if all of the different "flavors" vary only in how to implement some common behavior you might could use Strategy to implement that instead of having full subclasses for each network/type (although you might still want to use a factory method for instantiating the different strategy implementations).

Or it could just be too early and ENOCAFFEINE and I'm rambling . . .

[bliako]

Yes, I agree to your agreement. Do you have any proposal for "who owns the Factory" when Bod owns the "interface"/base-class and 3rd party develop different subclasses to it? Someone has to update the Factory...

[Fletch]

Hmmm . . . that's a good question; I was mostly thinking of this as the namespace being controlled by the factory author and not an open namespace with 3rd party implementors.

Maybe some sort of registry/plugin system that new subclasses could ask to be added to and/or be automatically added to if present in some special namespace but that (admittedly very handwavy vague idea) would be all I can come up with off the top of my head. Were my arm twisted I'd look to Java-land and see what sort of approach they take there (and some large grains of salt as well since it's not necessarily going to translate 1-to-1). I think there's stuff like how log4j handles this sort of thing similar problems with runtime specification of logging providers or backends that might provide inspiration.

Edit: tweaked l4j phrasing.

Edit again: Slightly (marginally so) more concrete thoughts: Mojolicious::Plugins might be another place to look for inspiration. Or Module::Pluggable, where the factory could consult each class in $self->plugins and if they have a register_social_class method call that (which returns maybe a list of the key it wants to be known by and a coderef to call to get an instance).