The plugin design pattern explained (as described by Martin Fowler)

Question

I am trying to understand and exercise the plugin pattern, as explained by Martin Fowler.

I can understand in which way it makes use of the separated interface pattern, and that it requires a factory to provide the right implementation of the interface, based on the currently used environment (test, prod, dev, etc). But:

• How exactly does the factory read the environment values and decide which object (implementing the IdGenerator interface) to create?
• Is the factory a dependency of the domain object (DomainObject)?

Thank you very much.

Backbone

For the users who will, maybe, decide to downvote my question: Please let me know the motive of your downvote, so that I can change my question correspondingly. I am open to all your suggestions, or critiques. Thanks. – Backbone

I didn't downvote, but I assume the down votes are a combination of too broad and primarily opinion based. – Misunderstood

Thank you, @markspace. I'll try to narrow it down to something more precise. – Backbone

Answer 1

You will want to get a full PFD of the "Patterns of Enterprise Application Architecture". What is visible on Fowler's site is basically first half-page of any chapter :)
What is being describes is basically the expanded version of idea behind polymorphism.

I don't think "plugin" can actually be described as a "pattern". It's more like result of other design choices.

What you have are .. emm ... "packages", where the main class in each of them implements a third party interface. Each of those packages also have their internal dependencies (other classes or even other libraries), which are used for some specific task. Each package has it's of configuration (which might be added through DIC config) ans each of them get "registered" in your main application.

The mentioning of a factory is almost a red herring, because these days that functionality would be applied using DIC.

Altorelievo

Thanks, teresko. I'll study your answer in-depth. I have to make some... "correlations", which may take a while. – Backbone

yeah ... it might a bit confusing - it's actually a "drunk post" – Arnitaarno

Cheers! And don't worry, I use a drunk post translator :-) – Backbone

I read your answer and I watched Misko's video. I correlated them with my system (which uses a DIC & multiple environments) and with Fowler's "Plugin" and... I got it :-) I really appreciate your help. Thank you again and good luck. – Backbone

@dakis can you please give us the link for "Misko's video"? – Phreno

@AhmadIsmail Hi. It's the link provided in the answer, regarding polymorphism: The Clean Code Talks -- Inheritance, Polymorphism, & Testing – Backbone

Answer 2

The goal of the Plugin pattern is to provide a centralized configuration runtime to promote modularity and scalability. The criteria that determines which implementation to select can be the environment, or anything else, like account type, user group, etc. The factory is just one way to create the desired plugin instance based on the selection criteria.

Implementation Selection Criteria

How your factory reads the selection criteria (environment state) depends on your implementation. Some common approaches are:

• Command-Line Argument, for example, CLI calls from different CI/CD pipeline stages can pass a dev/staging/production argument
• YAML Config Files could be deserialized into an object or parsed
• Class Annotations to tag each implementation with an environment
• Feature Flags, e.g. SaaS like Launch Darkly
• Dependency Injection framework like Spring IoC
• Product Line Engineering software like Big Lever
• REST Endpoint, e.g. http://localhost/test/order can create a test order object without notifying any customers
• HTTP Request Parameter, such as a field in the header or body

Dependency on Factory

Since the DomainObject calls the factory to create an object with the desired implementation, the factory will be a dependency of the domain object. That being said, the modern approach is to use a dependency injection (DI) library (Guice, Dagger) or a framework with built-in DI (Spring DI, .Net Core). In these cases, there still is a dependency on the DI library or framework, but not explicitly on any factory class.

Note: The Plugin design pattern described on pp.499-503 of PEAA was written by Rice and Foemmel, not Martin Fowler.

Francophobe