Re: Interface with implied Constructor
On Tuesday, July 9, 2013 12:41:28 PM UTC+2, Richard Maher wrote:
I have an interface that requires an implementer to cut code that 99%
sure is going to need some variables that are built at run-time. The
class to be developed will also be loaded at run-time via Reflection.
Most people I have consulted recommend going the null Constructor in
combination with Setters, or an INIT() method, to communicate the
ambient variables to the loaded class.
That's what I'd do as well: make that method part of your interface and be =
done.
I, on the other hand, would like
to go the Constructor-Injection-esque root of attempting to invoke a
version of the Contstructor with the arguments I specify.
Why do you want to do that?
(Maybe
failover to null constructor on InvocationException) Is there something=
intrinsically wrong with doing this in Java? (I know there are Abstract=
Classes but I have only Abstract Methods.)
I think it could be that you are making things overly complicated.
If you like to know the real example then what I'd like to pass to the
Constructor is the ParentFrame and an Application name.
London-to-a-brick the callee will create a Dialog Box.
An alternative approach would be to not configure the class and instantiate=
that via reflection but to use factory pattern: define another interface w=
ith a create method which receives all the necessary arguments and returns =
the interface you have already, load that class via reflection with default=
constructor and let it create instances as needed.
Cheers
robert