How to add supporting information to the existing java object?

Question

Is there a way or design pattern to add supporting information to the existing java object?

Example I have a model class Parent and it has child models. Its nothing but hibernate entities with parent-child hierarchy. The parent class object is being pass through multiple Java business rules class. I would like to add supporting information (might be DTO/VO) to the parent object which will be used in all business rules and also if any business validation errors during business logic it can be added to supporting information object.

Is there a better design to achieve this? Is it good to have a Context object which will be shared across? or better to add non persistent DTO/VO object to parent persistent object?

    Class Product {
    Set<Category> categories;
    ...
    ...
    }

    Class ProductProcessing1{
    void process(Product p) {
     }
    }
    Class ProductProcessing2{
    void process(Product p) {
     }
    }

All hibernate models are part of separate project called project-model and application is using that jar in class path. I would like to implement logic in Product processing rules for some specific products without altering product in project-model. Product specific supporting information should be carried over to all the processing rules. Project has more than 100 processing rules of validations. Also i would like to accumulate errors in each rules and save all of them at the end.

Answer 1

I would like to implement logic in Product processing rules for some specific products

This calls either for a specialization of the Product class, if you can make the difference at construction time, or for a decorator pattern if you need to dynamically add responsibilities and behavior to a product at run-time.

On the rule side, there is an issue if the same rules need to cope with both situations. In the specialization case and if you can afford to change the base class:

• you may just check if extra info is available. It's ugly but easy.
• you may consider a variant of the template method (where the template method would be in the rule and the primitive in the product).

A more elaborate approach would be to implement double dispatch. But it could complexify the rule class with several evaluation methods.

I would like to implement logic in Product processing rules for some specific products without altering product in project-model.

Specializations mentioned above are still candidate. But modifiying base class is excluded.

Product specific supporting information should be carried over to all the processing rules.

I'm not sure if the additional information is really specific to a Product object, independently of the rule engine, or if it is an additional information for a product that is specific to the rule processing.

So another approach could be to enrich the rule engine, and provide to every rule the extra information:

Class ProductProcessing1{
void process(Product p, Annotation x) {
 }
}

The annotation could convey the extra information without creating a coupling with Product. The Annotation class could offer a default implementation for Products without additional information, and a specialization for covering your case. This seems cleaner to me than any of the above.

By the way, have you thought of a rule engine, where the rules are specialization of an abstract rule class ? Just to avoid a lot of calls to specific rules ?

Is it good to have a Context object which will be shared across?

Using a single object to collect both the product specific errors and the rule based errors seems to create an unnecessary coupling between both worlds.

Sharing this Context object behind the scene seems no very future proof either.

If the Context object is the object invoking the rules for a specific Product, then it could be an option. But how would the rules know about it?