2

Imagine I have an application, which have plugin system.

  public class MyPlugin : Plugin
  {
        public override ExecuteImpl (Context ctx)
        {
              // do something...
        }
  }

Now I'm upgrading my application to version 2.0 with better plugin system.
Should I create Plugin2 type, and write adapter which allows to use Plugin as Plugin2,
or can I do something like this:

  public class MyPlugin : Plugin, IApiNewFeatures
  {
        public override ExecuteImpl (Context ctx)
        {
              // do something...
        }

        public void ExecuteNewApiFeatures () { ... }
  }

And in my app:

  if (myPlugin is IApiNewFeatures) { ... }

Is it good architecture? Adding new interfaces is easier I think, especially when application which uses that plugins belongs to someone else, and I dont want to bug his code.

  • 1
    The two things that worry me most in a case like this are: 1. Anything referencing your assembly has to be recompiled if this happens. 2. By your third new API set, you'll have a serious mess. – Magus May 5 '15 at 20:30
2

I don't think it is an "either or" question and you can avoid littering your code with

if (myPlugin is IApiNewFeatures) { ... }

Steps:

  • Define IPlugin with (the essential parts of) the public interface of your current Plugin class.
  • Put IPlugin its own source file.
  • Move the Plugin class' source file to a different folder (namespace) so it isn't readily available anymore. Then change your current code to use IPlugin references (instead of Plugin references) and only provide Plugin descendants with access to the Plugin class' source file.

Do this before you start the new plugin system. This will ensure that your old code does not need to be changed unless it really requires functionality from the new plugin system.

For your new plugin system

  • Define IPlugin2.
  • Make it a descendant of IPlugin. Add the methods that support the new api features.
  • Create Plugin2, descending from Plugin and implementing IPlugin2.

Deriving Plugin2 from Plugin ensures that the IPlugin methods (which are part of IPlugin2 by inheritance) are already implemented. Implement the new IPlugin2 methods.

All your new code can work with IPlugin2 references and not pay attention to whether the behavior comes from the new or the old plugin system. After all an IPlugin2 reference is also an IPlugin reference.

Old code that needs functionality from the new plugin system can now simply be changed to use an IPlugin2 reference instead of an IPlugin one. The code using the methods from Plugin/IPlugin will still work - after all (I)Plugin2 is (I)Plugin - and new/changed code now has the new functionality at its fingertips as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.