I created a library that extends off of another library written in C++, and now I'm porting this library over to Java (the original library that the C++ was written on top of already exists in Java). In the C++ code there is a purely virtual class called Stallable that is supposed to be used in order to add stall detection to a motor controller given a delta in voltage input. The class contains a purely virtual method getVoltage() which is used to supply a voltage source as they're several different motor controller classes, and some virtual functions to determine if there is a stall.
Classes would subclass this class, as well as a class from the original library (one that I do not have access to the code and for all intents and purposes otherwise can't modify), and would implement getVoltage(), and override any other methods that they might like. Then these objects can just be asked if there is a stall.
When I approach this problem from the Java side of things, my situation becomes a bit more tricky. I still can not touch the original class so refactoring the code is not an option, and users of my library should still be allowed to subclass or implement Stallable however they see fit.
Currently, the prospectives I see are as follows.
Stallable an interface and reimplement the stall detection logic it uses. In order to create the original functionality that the C++ codebase has I'd have to have classes subclass the original library and implement Stallable. This would work but would require the logic in the original purely virtual C++ Stallable to be reimplemented among any subclasses that I'd include, and any subclasses that end users would write.Stallable an abstract class that holds an object reference to a motor controller class from the original library. This preserves some of the functionality from the C++ code such that some methods would have to be overridden, and some are optionally overridden, however transparency is lost between this code and the C++ code. In C++, Since every subclass was a Stallable and a derivation off of the original motor controller, it became easy to toss pointers around to the object when the motor controller was needed, and when a Stallable object was needed. In this case, some type of accessor function would have to be implemented that returns a Java reference to the original motor controller that each Stallable subclass would hold on to. Transparency would be lost, but stall detection would easily be added.Obviously if I could modify the original classes for the various motor controllers this problem could easily be a matter of refactoring C++ code.
After researching the disparities between both languages' approach to OOP, I'm inclined to go with option 2 despite the friction it adds for my end users and the Stallable implementations I plan on including. I was asking if there was any other better ideas or insight before I start writing Stallable.java.
So basically what you want is that Java users of your lib to be able to implement an interface and behavior will be carried with it? That sounds like a job for AOP (Aspect Oriented Programming). With AOP (AspectJ, for instance) you can inject methods to classes that match certain criteria.
In your case, the criteria is "implementing the Stallable interface". The problem with AOP is that it is invasive. Your users will need to compile their classes using AOP or add AOP to their classpath if you opt to have runtime weaving.
Another option is to try to do some delegations using dynamic proxies.
Finally, you can try using bytecode manipulation http://asm.ow2.org/ in order to generate classes at run time.
Perhaps my answer can be less vague if you write a sample of how the Java code should look like.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments