Force a class to have certain static methods

[Chris]

How do I force a class to have certain static methods?

Here's the problem. Our system has certain pluggable classes. To make a
new implementation of such a class, you just have it implement a certain
interface.

I want to have these classes have certain static methods like getName()
and getDescription() that just return constants. The trouble is, you
can't put static methods in an interface. You also can't have static
abstract methods.

I could make these methods non-static, but then you'd have to actually
create each class just to get its description, and that's an expensive
process. The classes can contain data structures that are quite large.

What's the workaround?

 

[Lothar Kimmeringer]

What's the workaround?

There is none.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Patricia Shanahan]

How do I force a class to have certain static methods?

Here's the problem. Our system has certain pluggable classes. To make a
new implementation of such a class, you just have it implement a certain
interface.

I want to have these classes have certain static methods like getName()
and getDescription() that just return constants. The trouble is, you
can't put static methods in an interface. You also can't have static
abstract methods.

I could make these methods non-static, but then you'd have to actually
create each class just to get its description, and that's an expensive
process. The classes can contain data structures that are quite large.

What's the workaround?

If you are free to make major changes, you could go to a factory system,
and put the description etc. in the factory. Suppose your pluggable
interface is XXX:

interface XXXFactory{
XXX getInstance();
String getName();
String getDescription();
}

An XXXFactory would be cheap to create, and required to have the
methods. You would get an instance of the actual plug-in by calling the
factory's getInstance method.

If you cannot do something like this, or do not think it would make
sense in your context, consider leaving the static methods optional, and
providing defaults if the method does not exist, such as using the class
name for the getName() and getDescription() results. If the user wants a
more descriptive name, it is up to them to supply the static method.

Patricia

 

[Mark Space]

I want to have these classes have certain static methods like getName()
and getDescription() that just return constants. The trouble is, you
can't put static methods in an interface. You also can't have static
abstract methods.

I could make these methods non-static, but then you'd have to actually
create each class just to get its description, and that's an expensive
process. The classes can contain data structures that are quite large.
What's the workaround?

I also find that some of Java's limitation on interfaces and abstract
classes just don't make a lot of sense. I have no direct solution for you.

One thought: have each class implement an empty interface just to "mark"
it as a type that supports your descriptions. However, since you can't
actually guarantee these constants exist, you'll have to tease them out
with reflection to avoid throwing an error.

Note that "getName" already exists in the Class object, if the class
name itself will do.


You might want to declare a class for your constants, just to reduce the
likelihood that a programmer will make a mistake.

final class DescriptionConstants {
private String name;
private String desc;
DescriptionConstants( String name, String desc ) {
this.name = name;
this.desc = desc;
}
public String getName() { return name; }
public String getDesc() { return desc; }
}

class RandomClass implements DescriptionIface {
private final DescriptionConstants myConsts
= new DescriptionConstants( "some name",
"hey how bout those constants?" );
static DescriptionConstants getDesc()
{ return myConsts; }
}

Not "constants" but much cheaper than instantiating a complex class, and
there's a little protection for the harried programmer.

 

[Mike Schilling]

How do I force a class to have certain static methods?

Here's the problem. Our system has certain pluggable classes. To make
a new implementation of such a class, you just have it implement a
certain interface.

I want to have these classes have certain static methods like
getName() and getDescription() that just return constants. The
trouble is, you can't put static methods in an interface. You also
can't have static abstract methods.

I could make these methods non-static, but then you'd have to actually
create each class just to get its description,

That is, you'd have to instantiate an instance. You have to load the class
to call static methods on it.

Anyway, assuming you had some way to force the static methods to exist, how
would you call them? The only ways to call a static method without either
hardcoding the name of the class are

1. Via an instance, and
2. By reflection.

I'm ruling out 1 since you're trying to avoid creating an instance, so that
leaves 2..

and that's an expensive
process. The classes can contain data structures that are quite large.

What's the workaround?

If you're already using reflection, refuse to load the class unless it
defines all of the static methods you're interested in (which you can
document them in the interface definitions.). It's unfortunate that the
check is done at runtime instead of compile time, but c'est la vie.

 

[Lew]

Make them instance methods.

Nice, clean design.

Make them instance methods.

1. Via an instance, and
2. By reflection.

I'm ruling out 1 since you're trying to avoid creating an instance, so that
leaves 2..

Of course, if "efficiency" is your goal, then using reflection in lieu of
instantiation is not going to help you. /Au contraire/.

The overhead of creating instances is not large, and the need for polymorphism
suggests that you go right ahead and declare an interface, and use instance
methods to implement it. Then you'll have a nice clean design. If your
implementations deliver compile-time constants via the methods, they will be
inlined and your so-called "overhead" will vanish entirely.

 

[Lothar Kimmeringer]

The overhead of creating instances is not large,

depends on the content of the standard-constructor. And what
if the class in question doesn't have a standard-constructor?


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lew]

depends on the content of the standard-constructor. And what
if the class in question doesn't have a standard-constructor?

Then it's being constructed for other purposes anyway. If you design such a
class correctly, you'll only need the "overridable" constants in the context
of the use of such a class.

If that isn't true, which should be quite rare, refactor the "overridable"
constants into a helper class that *does* have a default constructor, and
include it in the complicated class. It should be clear that the
functionality of the "constants" is distinct from the functionality of the
complicated class, and should be refactored out.

If static methods of subclasses really, really, really have to be static, then
you just define them in each subclass. If you're designing a class to be
heritable with specific methods to override, then you design such a class to
be instantiated with the correct virtual functions.

In summary, if you encounter the scenario you described, redesign until it's
no longer incorrect.