Compile-time check of "static interface"

I

Ian Pilcher

I'm working on application that uses plug-in classes to handle various
data formats. No matter how I look at the problem, each plug-in class
has to implement a constructor (or static "factory" method) that takes
the appropriate agruments and another static method that checks the
compatibility of the class with a given data stream.

I'm using the reflection stuff in java.lang.reflect to check each class
when it's "registered". It's cumbersome, but it works.

The challenge comes from the "default" plug-in class. Just like it
sounds, it accepts any data format, and the program it written with the
assumption that it will always be present. Currently, it gets
registered during program startup, at which time the normal checks are
done -- with a RuntimeException thrown if I've forgotten to update the
default plug-in for a change in the required static method/constructor.

By all rights, this should be checked at compile-time. After all, the
default plug-in is part of the application. Is there any clean way to
do this?

Thanks!
 
C

Chris Smith

Ian said:
By all rights, this should be checked at compile-time. After all, the
default plug-in is part of the application. Is there any clean way to
do this?

To get a compile-time check of an API element, you need to have
something for it to conform to. That's not possible with either static
methods or constructors. So, you're looking at revamping the system to
use an instance method there. But that just pushes back the problem...
how do you create the instance so that you can call the instance method?

The answer is to use an interface that *won't* change for this
bootstrapping class. Specifically, require it to have a no-argument
constructor. The framework looks like this:

interface HandlerFactory
{
public Handler getHandler(Type1 param1, Type2 param2);
}

interface Handler
{
...
}

class DefaultHandlerFactory implements HandlerFactory
{
public Handler getHandler(Type1 param1, Type2 param2)
{
return new DefaultHandler(param1, param2);
}
}

class DefaultHandler implements Handler
{
public DefaultHandler(Type1 param1, Type2 param2)
{
...
}

...
}

So yes, you've still got an API element (the implicit no-argument
constructor to DefaultHandlerFactory) that has to match a specific
signature that is not checked at compile-time. However, you have no
need or desire to change that API element... and it's a simple one,
which even makes creating the factory easy from JNI code. The more
volatile code benefits from the compiler checks.

Does that fit your needs?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
I

Ian Pilcher

Chris said:
So yes, you've still got an API element (the implicit no-argument
constructor to DefaultHandlerFactory) that has to match a specific
signature that is not checked at compile-time. However, you have no
need or desire to change that API element... and it's a simple one,
which even makes creating the factory easy from JNI code. The more
volatile code benefits from the compiler checks.

I like the no-argument constructor idea. It allows me to move the
initialization into an instance method, which can be in the interface.
(I've got that why didn't I think of that feeling now.)

I was about to write that that still leaves me with the static
compatability checker, but, of course, that can be an instance method
too now, since instantiating the class will be so lightweight.

Great suggestion!
Does that fit your needs?

What I really "need" is static methods in interfaces. This will
certainly get me by for now.

Thanks!
 
L

Lee Fesperman

Ian said:
What I really "need" is static methods in interfaces. This will
certainly get me by for now.

You're not going to "get" static methods in interfaces. Google this group for the
reasons, and for workarounds.
 
I

Ian Pilcher

Lee said:
You're not going to "get" static methods in interfaces. Google this group for the
reasons, and for workarounds.

Next you're going to tell me that Santa Claus doesn't really exist!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top