It looks like you're new here. If you want to get involved, click one of these buttons!
Back when I introduced:
I encourages through it a design pattern, which in hindsight is pretty terrible. It can be broadly illustrated by this
The intention was to organise code. But it is flawed for the following reasons:
Using the inheritance chain break code into pieces, but there is was no implicit way of identifying what something comes from within those method, because it is all lumped together in the same pluign object and the methods are shared.
Much of the functionality that is commonly put in plugin classes has nothing to do with the pluggable API of the framework, so doesn’t actually need to be in there.
Although this pattern organised code, by moving it, it didn't solve this issue of not really having anything to do with Gdn_Pluign or the above point.
By virtue of coupling the work to the plugin instance through inheritance, this limits what other design patterns you can use, making it inflexible.
The order of the chain matters, when it really shouldn't be so strict, this can both cause practicability problems as well as not making sense depending on what it is you are trying to model.
Instead, I have come up with another design pattern, which I will be adding to Gdn_PScaffold (you would have to compile with
--legacy if you wish to use the old pattern).
The pattern I have come up with is called the Worker Domain design pattern.
Here is an example plugin which implements it:
It is not a be and end all, it might be to someone’s taste. Even I'm not going to implement on every plugin, especially small plugin which are pretty stable as it.
Follows are excerpt from the
grep is your friend.