Plugin Architecture/Design Pattern – is better to use a private Observer/Mediator Pattern for plugin subclasses or WP add_action?

by

I’m coding a very complex plugin which it’s organized as a parent “container” class and several subclasses, where each subclass is an optional/mandatory element which usually (but not always) maps to his own add_submenu_page.

Basically, it’s a plugin with his private set of let’s call them “subplugins”.

Every subclass/subplugin has its own (big) set of add_action and add_filter. So, technically speaking, my plugin’s subplugin is a valid WP plugin, simply it’s not called directly by WP itself.

Since i planned…actually tons of add_action…I’m wondering if i should refactor my plugin using a ‘private’ Observer/Mediator pattern ie. collect all relevant add_actions to my parent class only and baking up a pattern to notify/forward subclasses of events, reducing the impact of my plugin to WP event ques.

Is it a good idea or it’s absolutely not necesssary? Can u help me with some code for the class refactoring?

tnx in advance for help,
gabriele

3 Answers
3

I’m wondering if i should refactor my
plugin using a ‘private’
Observer/Mediator pattern ie. collect
all relevant add_actions to my parent
class only and baking up a pattern to
notify/forward subclasses of events,
reducing the impact of my plugin to WP
event ques.

The event queue is fundamental to WP, so it’s pretty fast and getting faster all the time.

So, I don’t think it makes any sense, performance wise, to make your own sub-queues.

Refactoring your code so that you don’t have to make each add_action() call manually is a different matter.

Leave a Comment