Forum Discussion
Wrapping classes vs. extending classes inside of Advisor
Wrapping classes vs. extending classes inside of Advisor
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. (http://blaze.i.lithium.com/i/smilies/16x16_smiley-wink.gif)) 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.
5 Replies
I agree with you, but also you can wrap the class inside of Blaze Advisor instead of using an external java class or a .Net object. You can create an object inside Blaze that wraps the Foo class (great name, indeed) and then you add the needed properties to the class in Blaze Advisor avoiding using external objects.
- Not sure that I understand your meaning when you say "wrap the class inside of Blaze Advisor". Can you be more specific?
- What I mean is if you create a new object inside Blaze, that object can contain the Java object + the fields you need to add.
Unfortunately your description fits class extension as well as wrapping. I was looking for something more specific.
Assuming that we don't have any lingering confusion about the difference between the two approaches, my question to you would be--why define the wrapping class inside of Advisor? What advantages does that approach provide? In our experience, the other fields on the wrapping class are being added to help the Advisor project navigate a flattened BOM. We find it advantageous to set their values in the class constructor outside of the Advisor project in order to help keep that logic distinct from the actual business rules. The wrapping classes are also then exposed to the outside (non-Advisor) world, in case anyone needs to look at the class definition.
One guess at your possible response ito the above questions is that the wrapping classes then don't have to be imported into the Advisor project. However, if you put them in the same package, the effort involved in importing is trivial.
As I said from the beginning I completely agree with you in the way you show how to wrap classes outside from Blaze, I just wanted to point to another way to do it inside. Once we are agree that is possible to wrap them outside and inside, the discussion should be when and why. You point a very important reason to do it externally which is to use in the external world, so I must agree that for commonly used classes wrap it externally is the way.
I must say that the first reason which comes to my mind to use it internally is easiness, Blaze let us extend the class without using any other tool. Besides, I would say that any case is different and has a different solution, so it’s not possible to say which way is better for every case.If you get some day with a specific case where you have any doubt please bring it up front and we can discuss it deeply.
