Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin pattern #351

Open
iluwatar opened this issue Jan 16, 2016 · 21 comments
Open

Plugin pattern #351

iluwatar opened this issue Jan 16, 2016 · 21 comments

Comments

@iluwatar
Copy link
Owner

iluwatar commented Jan 16, 2016

Description

The Plugin design pattern allows a software application to support extension through third-party plugins, providing flexibility and scalability. This pattern is particularly useful for applications requiring dynamic and interchangeable components.

Main Elements of the Plugin Design Pattern:

  1. Plugin Interface: Defines the methods that plugins must implement.
  2. Concrete Plugins: Implementations of the plugin interface, providing specific functionality.
  3. Plugin Manager: Responsible for loading, initializing, and managing the lifecycle of plugins.
  4. Application Core: The main application that uses the plugin manager to interact with plugins.

References:

Acceptance Criteria:

  1. A Plugin Interface is defined with necessary methods that plugins must implement.
  2. At least two Concrete Plugin implementations are created, showcasing different functionalities.
  3. A Plugin Manager class is implemented to handle loading, initializing, and managing the plugins.
  4. Demonstration of the pattern in a sample application, showing dynamic loading and usage of plugins.
@skylermj-252
Copy link

Hello I am ready to tackle this issue. Is there any information I need to read to understand this issue?

@npathai
Copy link
Contributor

npathai commented Feb 12, 2016

@skylermj-252

This pattern is described in Patterns of Enterprise Application Architecture book.

Brief description about the pattern:

  • Separated Interface: Some behaviors implementation must be chosen dynamically based on runtime environment. Different environments include Unit Testing, Stress Testing, IoT, Production. Ex of such a requirement is ID generator, in unit testing environment in memory counter based solution should be chosen and in production DB based counter must be chosen.
  • Dynamic linking: A plugin implementation is not known during compile time. The actual implementation is chosen based on configuration at runtime, and the class is loaded using reflection. The configuration can be a text file containing full path of plugin class.
  • Reconfiguration: Reconfiguration will not require rebuild, as we have them loaded dynamically. I am thinking about a valid use case for this. I will comment as soon as I find an appropriate use case.
@npathai
Copy link
Contributor

npathai commented Feb 12, 2016

Random thoughts on reconfiguration: Java does not allow reloading same class. So I guess reconfiguration means switching from one implementation to other. Like switching from In Memory Counter implementation to DB based counter.

@geniusgeek
Copy link

The best implementation approach for this pattern is to use annotations,
reflection and dynamic binding in java, and Abstract Factory combined with
Strategy pattern so as to give the desired flexibility.
Although i am really busy presently, but i will love to render my
assistance in any way.

Cheers.

On Fri, Feb 12, 2016 at 11:13 AM, Narendra Pathai notifications@github.com
wrote:

Random thoughts on reconfiguration: Java does not allow reloading same
class. So I guess reconfiguration means switching from one implementation
to other. Like switching from In Memory Counter implementation to DB based
counter.


Reply to this email directly or view it on GitHub
#351 (comment)
.

amitjoy added a commit to amitjoy/java-design-patterns that referenced this issue Mar 2, 2016
amitjoy added a commit to amitjoy/java-design-patterns that referenced this issue Mar 12, 2016
@iluwatar
Copy link
Owner Author

This issue is free for taking again.

@abhi-agr
Copy link

Hi,
I see that there is a commit to this issue already but it is still open.

What are the next steps here - Work on existing commit from @npathai or write the solution from scratch?

Can the new person decide what is the right next step?

@iluwatar
Copy link
Owner Author

iluwatar commented Aug 1, 2018

@abhi-agr you can write the implementation from scratch or utilize @npathai's solution if you wish. Will you work on this?

@abhi-agr
Copy link

abhi-agr commented Aug 1, 2018

I am planning to work on this. But I think I need to compare different strategies - OSGI and JPF to find out the better implementation.

Let me come up with a design and later I can move to implementation

@iluwatar
Copy link
Owner Author

iluwatar commented Aug 7, 2018

@iluwatar
Copy link
Owner Author

iluwatar commented Oct 5, 2019

Issue free again

@LiHao-MS
Copy link

LiHao-MS commented May 8, 2020

please check it.

@iluwatar
Copy link
Owner Author

iluwatar commented Jul 6, 2020

@jasciiz are you still working on this?

@ohbus ohbus linked a pull request Jun 14, 2021 that will close this issue
@iluwatar
Copy link
Owner Author

This issue is free for taking again.

@lkpengcs
Copy link

hi, can I work on this issue?

@iluwatar
Copy link
Owner Author

iluwatar commented Jul 1, 2022

Yes @lkpengcs, go ahead

@iluwatar
Copy link
Owner Author

@lkpengcs are you working on this?

@lkpengcs
Copy link

Sorry, I am a little busy these days and cannot work on this.

@Kaiyan1Zhang
Copy link

May I try to implemented this issue?

@iluwatar
Copy link
Owner Author

@stale
Copy link

stale bot commented Nov 28, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment