Re: Interface with implied Constructor

From:

Daniel Pitts <newsgroup.nospam@virtualinfinity.net>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 09 Jul 2013 21:41:05 -0700

Message-ID:

<BB5Dt.59986$hK5.30896@fx15.iad>

On 7/9/13 3:41 AM, Richard Maher wrote:

Hi,

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. 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. (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.)

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.

Cheers Richard Maher

Perhaps you need two interfaces instead. A factory interface, and the
actual business object interface.

Another way to handle this is to have some sort of injection where you
pass in only objects the class requires. For instance, Guice will let
you annotate a class and it will manage creating the instance for you,
injecting any objects (either via constructors or setters) that the
object needs. Spring beans will do similar things, but is more common
in web frameworks than GUIs.