This PR introduces a few refactors to the Plugin and ModelSpec APIs:
Plugins are now required to have a 0-arg constructor, and are initialized via an init() method. A plugin that does not want to handle a particular model spec can return false from the init method, and it will be discarded. This replaces hasChangesForModelSpec() makes it easier/safer for a plugin to initialize its internal state outside of its constructor, and then only if it wants to.
Plugin itself is now an interface, with AbstractPlugin provided as a stub class to extend. This is intended to mirror how the Processor/AbstractProcessor API is designed.
ModelSpec and its associated subclasses are now constructed via a factory instead of directly (making their constructors hidden). Some business logic has been moved from the ModelSpec constructor into an initialize() method, which is called by the factory. This will make it easier to write better tests for model specs someday.
will/did naming scheme in plugin has been reverted to the old before/after naming scheme.
jdkoren
commented
7 years ago
This PR introduces a few refactors to the Plugin and ModelSpec APIs:
init()method. A plugin that does not want to handle a particular model spec can return false from the init method, and it will be discarded. This replaceshasChangesForModelSpec()makes it easier/safer for a plugin to initialize its internal state outside of its constructor, and then only if it wants to.Pluginitself is now an interface, withAbstractPluginprovided as a stub class to extend. This is intended to mirror how theProcessor/AbstractProcessorAPI is designed.ModelSpecand its associated subclasses are now constructed via a factory instead of directly (making their constructors hidden). Some business logic has been moved from theModelSpecconstructor into aninitialize()method, which is called by the factory. This will make it easier to write better tests for model specs someday.will/didnaming scheme in plugin has been reverted to the oldbefore/afternaming scheme.