Is there a name for this pattern?

Is there named pattern where a class will delegate object construction to another class by passing it a factory that is used for the construction?

Ok that’s really vague, what I’m using this for is to make a plugin system of sorts and passing required factories to the plugin.

For example:


interface Plugin {
	public function getForm(FormFactory $formFactory);
	public function getView(ViewFactory $viewFactory);
}

//These "plugins" have no (or few) constructor dependencies of their own but are passed dependencies
//to allow them to construct related objects. 
//It's not a true dependency because the plugin should not need FormFactory/ViewFactory in any other method.


class Plugin1 implements Plugin {
	public function getForm(FormFactory $formFactory) {
		return $formFactory->create('Form1');
	}
	
	public function getView(ViewFactory $viewFactory) {
		return $viewFactory->create('View1');
	}
}

class Plugin2 implements Plugin {
	public function getForm(FormFactory $formFactory) {
		return $formFactory->create('Form2');
	}
	
	public function getView(ViewFactory $viewFactory) {
		return $viewFactory->create('View2');
	}
}

class MyPluggableObject {
	public $viewFactory;
	public $formFactory;
	public $plugin;
	
	public function __construct(Plugin $plugin, FormFactory $formFactory, ViewFactory $viewFactory) {
		$this->plugin = $plugin;
		$this->viewFactory = $viewFactory;
		$this->formFactory = $formFactory;
	}
	
	public function doSomething() {
		//Instead of creating the form/view directly from the factory,
                //pass them to the plugin 
		$form = $this->plugin->getForm($this->formFactory);
		$view = $this->plugin->getView($this->viewFactory);
	}
}

new MyPluggableObject(new Plugin1, $formFactory, $viewFactory);
new MyPluggableObject(new Plugin2, $formFactory, $viewFactory);

This allows the different instances “MyPluggableObject” to have different forms and views depending on which plugin was passed to it.

I’m trying to avoid the use of the word “Plugin” because I know it’s not accurate. Really I’m just trying to get my terminology right :stuck_out_tongue:

I’m not sure I explained it very well but hopefully the code is clearer.

I hear man. “Would a rose by any other name, still smell as sweet?” LOL

I am a stickler for naming myself, but if you were looking for a GoF pattern to describe the problem, I don’t think there is one. That is not to say, there isn’t a pattern out there, as there are literally thousands of unpublished patterns. Phrasebook is one such pattern discovered/documented by some University students I believe.

Anyways, plugin does suggest plug and play fucntionality, I agree.

So lets go through some names?

  1. Dropin
  2. Filter
  3. Callback
  4. Event sink/listener
  5. Signals/Slots
  6. Extension/Component/Module

All of which are used in existing technologies, so…

They’re filling in otherwise missing behavior rather than extending it

I find this to be the most interesting statement and most descriptive.

Patch? But it’s not a fix, it’s filling in the blanks. Placeholder, but that is commonly used in template nomenclature.

How about calling it a “fixin”?

You would have to go through a tedious process to prove this pattern indeed applies to a problem that has not yet been addressed. Driving forces, side effects, etc. Before anyone took this pattern seriously, but for yor own internal purposes, no one can stop you and if it helps disambiguate your fixins from your plugins, you will have that much more easier time explaining code to other developers.

Cheers,
Alex

I was kinda hoping there was a pattern which covered it a bit more specifically than that :stuck_out_tongue:

Well it’s sort of the delegate pattern but it’s more than that: I’m passing specific dependencies to the methods on the delegate. The delegate isn’t meaningful without its container and the container can’t work without a delegate.

My goals are a mix between abstract classes: requiring behaviour to be completed elsewhere
and the decorator pattern: extending the functionality at runtime

The difference is, unlike the decorator pattern, I want to keep the bulk of the logic in the containing class, rather than decorating specific parts.

It just seems odd to me that there’s no standard pattern for this.

I suppose my real question is, what should I call my “Plugin” classes?

edit: To elaborate on this, the “plugins” would be as minimal as possible and any business logic would be contained within “MyPlugableObject”

I was kinda hoping there was a pattern which covered it a bit more specifically than that :stuck_out_tongue:

Thats common, but I think it’s important to realize that a solution cannot always be described concisely as a single pattern, sometimes, solutions are best described as a composition of two or more patterns.

I suppose my real question is, what should I call my “Plugin” classes?

Your plugins (including MyPlugableObject) could possibly be facade?!?

EDIT | After some consideration your plugins are not really facade. MyPluggableObject could still possibly be. The plugin methods are almost adapters that delegate to an injected factory method. To be honest that indirection is confusing me, so I probably don’t understand the problem well enough to really be commenting, I just have an opinion about everything. :stuck_out_tongue:

The plugin class itself, seems to be a simple container that implements getForm() and getView() methods. If you are looking for a pattern to describe that itself, not the individual methods and implementation, I am at a loss for words, other than ‘plugin’ or ‘container’

Cheers,
Alex

You would have to go through a tedious process to prove this pattern indeed applies to a problem that has not yet been addressed. Driving forces, side effects, etc. Before anyone took this pattern seriously, but for yor own internal purposes, no one can stop you and if it helps disambiguate your fixins from your plugins, you will have that much more easier time explaining code to other developers.

I’m not trying to create a pattern :p. There isn’t anything new here, which is why I expected there would be something similar with an existing definition.

After looking through the list of patterns on wikipedia I think the closest match is the decorator pattern:

The decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all instances of the original class; decorating can provide new behavior at runtime for individual objects.

Which does describe what I’m trying to achieve, only my approach is inverted: passing the extended functionality into the original object (as a delegate) rather than wrapping it… because it’s required behaviour rather than extended behaviour.

The delegate pattern:

Suggests the term “Helper” which I think, actually, is quite suitable.

Well I dislike the word plugin for several reasons:

-Usually it’s used to describe optional extras which can be turned on/off at will. In this case they’re required
-Generally you can have multiple plugins for a specific container, in this case this relationship will always be 1:1
-They’re filling in otherwise missing behavior rather than extending it

  1. Factory
  2. Delegate
  3. Builder

Are the three patterns that jump out at me, with other buzzwords being:

  1. Dependency Injection
  2. Inversion of Control

MyPluggableObject I would describe as builder pattern, possibly a facade.

The getForm() and getView() methods are delegates, as they simply seem to pass the buck to the factory method of the injected object.

Cheers,
Alex