Re: Accessibility of suBclass-fields from suPERclass (reflection)
On 8/17/2014 1:42 PM, Andreas Leitgeb wrote:
Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
On 8/17/2014 6:51 AM, Josip Almasi wrote:
On 08/17/2014 02:22 AM, Eric Sosman wrote:
On 8/16/2014 6:37 PM, Andreas Leitgeb wrote:
Overall-operations, (e.g. resetting all values of a given subclass
instance) are done from Base-class by use of reflection.
Why by reflection? Why not by a reset() method, abstract in
the superclass?
Because it means coding in each subclass?
That really is the reason. And it's not just the reset(), but also
another bunch of methods.
I think there are two ideas you need to consider.
1) Make the fields in the sub classes protected instead of private.
This will allow you to avoid the setAccessible call.
(yes - protected allows not only access from below but also
access from above)
Saving a line of code is not important, but you will also get
rid of the restriction that your code will not run with a
security manager in place.
And I don't like to have such environmental restrictions
in code if it can be avoided.
2) Replace the reflection code in the base class with a
cast to an interface and call of method - and use AspectJ
to add interface and method implementation to all sub classes
of the base class.
You still have the reflection code. But you have separated
the business logic code in the base class and reflection code
in a separate aspect.
So if a business logic code maintainer (or a code maintainer just
with his business logic hat on) need to look at the code, then the
base class just calls a method and that method is documented in
the JavaDoc for the interface - no need to dig down into the
reflection code.
The framework code maintainer (code maintainer with framework
hat on) can focus on the aspect.
Arne