Plugin Based Architectures Elvira: Problems and Solutions

1. Plugin Based ArchitecturesElvira: Problems and Solutions Andrés R. Masegosa Department of Computer Science and A.I. Univerisity of Granada Puerto Lumbreras, June 2008

2. Why extends is evil?[javaworld.com] • James Gosling (Java’s inventor): “If you could do Java over again, what would you change?” “I’d leave out classes” • The real problem is the inheritance. • “You should avoid implementation inheritance whenever possible”: Interfaces versus Classes

3. Interfaces versus ClassesThe flexibility Issue • “You start programming before you fully specified the problem”: • Incorporate newly discovered requirements into the existing code as painlessly as possible Interface Collection LinkedList Interface Collection HashSet No Interface Use

4. Interfaces versus ClassesThe NodeList Case: Unsorted and Sorted NodeList • Firstly, a linear time for searching in a NodeList is acceptable. • But… gene expression data appears (thousand of variables), so we need logarithmic access time (sorted). • Sorted NodeList inclusion suppose a complexity introduction: “One class has to manage the two versions” • Solution: NodeList as Interface • SimpleNodeList manage the simple version. • SortedNodeList manage the sorted version. • No changes in the rest of the code (except at the constructors!!!!!!!).

5. CouplingConfiguration and ContinuousConfiguration • Configuration of Continuous Variables seems a subclass of Configuration. • ContinuousConfiguration inherits from Configuration. • Hard to change the implementation: HashTable or Ordered version (There aren’t interfaces)

6. CouplingConfiguration and ContinuousConfiguration: Problems • Some methods are valid for Configuration and not for Continuous Configuration, but they are active and can’t be used: public int getValue(FiniteStates var) void setValue(FiniteStates var, int value) • Some methods are implemented in Configuration and not overwritten in ContinuousConfiguration, but they can’t be used: public isCompatible(Configuration conf) void double hashCode() • All of them provokes runtime errors not compiling time errors. As more more funcionalities are added as stronger these problems becames.

7. Vector X1 1 X2 0 X3 0 X4 1 Vector CouplingConfiguration and ContinuousConfiguration: Solution • Configuration represents a set of assigments or instatations of a set of random variables. • Everything is Discrete: FiniteStates, int… implements Interface Configuration Class SimpleConfiguration void setVars(Collection Vars) void setValues(Collection Values) void setVar(FiniteStates var) void setValue(FiniteStates var, int v) FiniteStates getVar(int pos) int getValue(int pos)

8. CouplingConfiguration and ContinuousConfiguration: Solution • A new Interface is defined: • Incompatible methods are removed: void int getValue(FiniteState node) • Not defined methods are removed: void int possibleValues() Interface Configuration Interface ContinuousConfiguration void setVars(Vector Vars) void setValues(Vector Values) void setVar(FiniteStates var) void setValue(FiniteStates var, int v) FiniteStates getVar(int pos) int getValue(FiniteStates var) int possibleValues() void setVars(Collection Vars) void setValues(Collection Values) void setVar(Node var) void setValue(Node var, int v) Node getVar(int pos) double getValue(Node var)

9. Vector Continuous X6 1.5 X7 1.3 1.2 X8 1.5 X9 Vector Doubles CouplingConfiguration and ContinuousConfiguration: Solution implements Interface ContinuousConfiguration Class SimpleContConfiguration • void setVars(Collection Vars) • void setValues(Collection Values) • void setVar(Node var) • void setValue(Node var, int v) • Node getVar(int pos) • double getValue(Node var) Configuration conf = new SimpleConfiguration() double getValue(Node var) { if (var.isDiscrete()) return (double) conf.getValue(var) else return valCont.elementAt(index(Var); } void setVar(Node var) { if (var.isDiscrete()) conf.setVar(var) else varCont.insert(var) }

10. CouplingConfiguration and ContinuousConfiguration: Solution • Advantages: • It is easier to change the underlying implementation. • We can even have several implementations: • Configuration using HashTable. • Configuration using Ordered List. • We would only need to change the constructor. • Disadvantages: • Introduction of some duplicity in source code.

11. Agglomeration of FuncionalitiesDataBaseCases Class • DataBaseCases manages the input, storage and output of the data. • Complexity of the class (without inheritance): • 8 different constructors. • >80 methods • Very different methods: • divideIntoTrainAndTest  Classification • getPotentialTable  Learning • logLikelihood  Clustering • Confusion in the class and for the programmer.

12. Agglomeration of FuncionalitiesNode Class • Node represents a generic random variable. • Complexity of the class (without inheritance): • 35 different fields. • >90 methods • Very different methods: • getChildren  GUI, Inference, Learning • getNeighbourAt  Inference • getVisited  Learning, Classification • Again, confusion in the class and for the programmer.

13. Agglomeration of FuncionalitiesNodeList Class • NodeList represents a list of nodes. • Complexity of the class (without inheritance): • 7 different constructors. • >50 methods • Very different methods: • subSetsOfSize, randomOrder Learning • getNodeString  GUI • isIncluded Inference • Again, more confusion in the class and for the programmer.

14. Agglomeration of Funcionalities Strange Classes • There are many classes that are only used in a mininum part of the code: • NodeQueue  ProbabilityTree • ContinuousCaseListMem  Learning • RelationList  Inference • Many different classes creates confusion and delay development times. • Very differents requirments among some modules: • learning, inference, classification, influence diagrams, gui…

15. Agglomeration of FuncionalitiesConfusion in Concepts • What’s a Node is? • Node in an Aciclic Graph. • Node in a Decision Tree. • A simple random variable of a data base. • Tracking an important error: • NodeList copy(): • copy.insertNode(node.copy()) OR copy.insertNode(node) • node.copy() removes parents and child information. • node without copy made a shallows copy of NodeList. • Solution: • Create two different methods but complexity is added to the code.

16. Plugin Based ArchitecturesIntensive use of Interfaces • Based on several principles: • Hollywood’s: “Don’t call us, we’ll call you’ • Inversion of Control: • When Library Methods calls User Methods • Basically, you firstly define what you need and after you find out how you can implement it. • It is very generalized among important software programms: • Eclipse  Almost an standard for plugin development. • Firefox, Thunderbird, Microsoft Outlook, IE Explorer… • Some research tools: Bioclipse (biological data analysis), Spamato (spam filtering), GumTree (scientific experiment platform),…

17. Plugin Based ArchitecturesPlugin Definition • What is a plugin? • .jar File + plugin.xml • … and the key concepts: • Extension Point: • An Interface + XML • When a plugin wants to allow other plugins to extend or customize some funcionalities. • Extensions: • A class that implements the interface of some extension point

18. Plugin Based ArchitecturesPlugin Definition: An example • Let’s see an example: • Classifier and Evaluation would be the extension point: public interface Evaluated { String objectName (); double evaluate (DataBaseCases database, int c); } public interface Classifier { void learn (DataBaseCases training, int c); Vector classify (Configuration instance, int c); } TreeClassifier Plugin Classification Plugin Evaluation Plugin Classifier Evaluation Weka Plugin

19. Plugin Based ArchitecturesPlugin Definition: An example Classification • How to use an special data base for classification: public interface DBClassifiy { DataBaseCases getData() int getClassIndex() void setData(DataBaseCases db) void setClassIndex(int index) } public interface ClassifierImprove { public void learn (DBClassifiy training); public Vector classify (Configuration instance); } public class ExtensionDBClassifiy { DataBasesCases case=null; int classIndex=-1 DataBaseCases getData() int getClassIndex() void setData(DataBaseCases db) void setClassIndex(int index) } publicinterfaceEvaluatedImprove { String objectName (); double evaluate (DBClassifiy database); }

20. Plugin Based ArchitecturesPlugin Definition: An example Classification • The solid line indicates a common import… SimpleConfiguration HashConfiguration Elvira Core Plugin Configuration TreeClassifier Plugin DBClassify Classifier Evaluation ClassifierImprove Evaluation Improved Classification Plugin Evaluation Plugin Weka Plugin

21. Plugin Based ArchitecturesAdavantages • You can specify what you need before it is implemented. • You reduce the coupling among classes with Interfaces. • You allow external plugins to create their own classes (DBClassify) without introduce complexity in the basic plugins. • You can have different implementations of a core funcionality (i.e. Configuration normal or Hashtable or Ordered) at the same time. You just change the extension • Very flexible and easily extended by third-parties.

22. Plugin Based ArchitecturesDisadvantages • Suppose a change in our programming habits. • There will be appear duplicated source code. • It could be hard to decide what is included in one plugin and what is included in another plugin. • It could be hard to decide what is a simple class and what is an interface or an extension point. • Introduce some complexity in the source code. • We would need to choose a plugin framework: eclipse, java plugin-framework…

23. ENDAny questions?