Paul Armborst

Wrapping classes vs. extending classes inside of Advisor

Discussion created by Paul Armborst on Oct 2, 2008
Latest reply on Oct 21, 2008 by Julian Ariza

Sometimes there is the need to add fields to existing classes in order to facilitate easier authoring of rules.  The Advisor documentation tells you that you can extend a class inside of Advisor.  And you can.  However, there is a problem with this approach.

 

Let's say that you have a class in your BOM to which you want to add a field.  However some instances of that class are already subclassed in Java (or .Net).  Let's call the base class Foo and the extended class FooExtended.  (It took me alot of time to come up with those names.:smileywink:)  Which class do you subclass inside of Advisor?  You can't subclass FooExtended, because not all members of the Foo class are instances of FooExtended.  (Can you say ClassCastException?)  If you subclass at the Foo level, you lose access to the fields on FooExtended.

 

Flexibility is the reason why you want to wrap Foo instead of extending it.  Write a wrapper class in Java (or .Net) that includes the instance of Foo (or FooExtended--use a common parent class) as an attribute along with the other fields that you would have extended the class with inside of Advisor.  Put logic to populate the other fields either in the wrapper class itself, or in the Advisor project.  At the start of the Advisor project, traverse the BOM and instantiate an instance of the wrapper class whenever you encounter an instance of Foo or FooExtended.  When you access the wrapper in a rule, you can cast it as whatever it needs to be in order to use it properly.

Outcomes