HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Worker Domain design pattern

Back when I introduced:

https://github.com/x00/Gdn_PScaffold

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:

https://github.com/x00/WorkerDomain

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 README.md

grep is your friend.

Comments

  • About

    This plugin is an example of the Worker Domain design pattern. It is a working example and I have been generous with annotating the code with documentation.

    This pattern was developed with pluggable APIs in mind. Particularly for the Vanilla/Garden framework, which this example uses.

    Place in the plugin directory an enable it the normal way.

    You can access the "Hello World" by going to /helloworld and you can change the settings at /settings/workerdomain

    However more interesting is the plugin code itself.

    grep is your friend.

  • Intro

    A common way of extending code besides overwriting, is to make use of event hooks and other special functions/methods that will be called by the framework's pluggable API.

    I use 'Hooks' broadly here to denote anything that inserts, overrides (overloads), or adds new functionality through documented means. So it can include an MVC framework a convention to create new controller methods dynamically for or 'magic' __call methods.

    This example was specifically designed with pluggable MVC frameworks in mind but may be adapted for others.

    There are two common styles of pluggable APIs, preregistered hooks, where functions and object methods are explicitly registered to an event like Wordpress, or named convention based implicit methods which is more in the the style of Vanilla/Garden.

    Either way you often see a class (or file containing functions) specifically to be the interface with all these hookable events, which is the convention in Garden plugins or theme and application hooks files and what I have in mind for this example.

    I didn’t design this for Applications as a whole, but specifically for the increasingly popular way of extending, and adapting functionality within frameworks, and their applications.

    grep is your friend.

  • I'll come back to explain specific code candy in this implementation, which is not require by this pattern but could be useful for plugin development, and is implemented in the worker domain way.

    grep is your friend.

  • It's a very interesting topic, thank you for sharing. More explanations are always welcome.

    There was an error rendering this rich post.

Sign In or Register to comment.