CODEWITHSUNDEEP
oopdesign-patternspluginsfactory-pattern
PajuranCodes
PajuranCodes

Reputation: 471

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

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:

Thank you very much.

Upvotes: 12

Views: 23648

Answers (2)

DV82XL
DV82XL

Reputation: 6639

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.

Upvotes: 8

tereško
tereško

Reputation: 58444

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.

Upvotes: 4

Related Questions