OpenEngSBModel code weaving

[thrau]

Hi!

i have a proposal regarding the ManipulationUtils and the way the OpenEngSBModel code is weaved.

Right now, each method body is dynamically built via StringBuilders and directly injected into the @Model annotated class. Some of the functionality is fairly complex which makes it hard to read, test and maintain.

What if instead, the functionality is capsuled into an abstract implementation of an OpenEngSBModel (let's call it 'EnhancedOpenEngSBModel') in a decorator/proxy type way? The byte-code-injected Model would then hold an instance of this enhanced model and proxy all calls of the OpenEngSBModel interface towards this instance. The EnhancedOpenEngSBModel instance itself again holds the model instance which it decorates (creating a cyclic dependency), and in turn reflectively reads the model class structure and properties. This is much like multiple inheritance is commonly simulated in java.

I've sketched this down into a gist paste [1].

It is possible, that there is some flaw in my concept that I'm missing, however this would reduce the amount of LoC weaved and make the actual functionality a lot more maintainable and testable.

WDYT?

br,

Thomas

--

[1]: https://gist.github.com/thrau/5d84adcc31ea2be3294d

[Felix Mayerhuber]

Hi,

while I'm with you that this method has an easier maintainability, I
suppose the weak point in this is that you need for almost every call
against a model to analyze the whole class via reflection over and over
again, while in the way it is done now, you only need to do this once
(during the weaving process) and afterwards the logic is "hard" in the
model itself.

I think this needs to be discussed, since it really depends on the
amount of model function calls if the maintainability increase is worth it.

Kind regards,
Felix

[Felix Mayerhuber]

What came to my mind just now: Wouldn't this structure also make trouble in remoting? I suppose jackson is not able to deal with cyclic dependencies in the objects?

Kind regards
Felix

[thrau]

one could lazy-init all the reflection, to reduce reflection calls. this would probably only slightly increase the memory required.

as far as remoting concerns, jackson has mechanisms to handle exclusion of circular references.

i haven't entirely thought this through yet, but maybe it's possible to detach the model instance from the EnhancedOpenEngSBModel entirely, leaving out the circular referencing. Maybe it's enough to just hold the Class object of the Model, and pass the reference to the enhanced model where needed via parameter.

[thrau]

apparently jackson supports bi-directional referencing since 2.0 [1]

br,

thomas

--

[1]: http://www.cowtowncoder.com/blog/archives/2012/03/entry_466.html

[Felix Mayerhuber]

How do you mean that with lazy-init the reflection? I mean, you can
analyze the class in this other class and save the structure of it in a
separate data structure in the wrapper class, but I don't think that is
really worth it? Or, if you mean to just execute the reflection once and
save the result, will not work, since calls like toOpenEngSBModelEntries
will not always return the same result. I'm kind of confused ^^

Ok, so there are ways to do it in remoting.

Maybe we need opinions from others on this?

Kind regards
Felix

[thrau]

sounded more complicated than i meant it. all i meant was doing:

private String name;

public String retrieveModelName() {
    if(name == null) {

        name = model.getClass().getName();

    }

    return name;

}

alternatively one could just analyze the class once when initialising.

[thrau]

obviously, property values of model instances have to be read reflectively every time in any case.

[Andreas Pieber]

I'm curious but have you also considered cases where your model already has a base class? Do you plan to walk down the path to object?

Another point not making me too happy about this change is that we'll also have to adapt the bridges.

How much do we really have to maintain/change in the model weaving?

Kind regards,

Andreas

--
You received this message because you are subscribed to the Google Groups "OpenEngSB developer discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openengsb-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.