Re: abstract static methods (again)
Eric Sosman wrote:
Daniel Pitts wrote:
Eric Sosman wrote:
Tomas Mikula wrote:
[...]
1. serialization frameworks. It is already required that a
Serializable class has a no-arg constructor. But this is not
required at compile time.
You've said this a couple times, but are you sure it's true?
This class (with no no-arg constructor) appears to serialize and
deserialize just fine:
Only the non-Serializable Base of a Serializable class requires a
no-args constructor: [...]
Right. Which means that if an interface could mandate a specific
constructor for its implementing classes, this capability would not
solve Serializable's problem at all: It's not the Serializable class
that needs the special constructor, but a superclass that *doesn't*
implement Serializable. If we get to the point where an interface
can impose requirements on the classes that *don't* implement it, I
think we've achieved absurdity ;-)
There may yet be a reasonable use case for letting an interface
or abstract class require specified constructor signatures of the
implementing subclasses, but Serializable isn't it. The others I've
seen mentioned in this thread don't seem compelling -- but, as I've
also said in this thread, my experience with such things is slight.
I'm still willing to be convinced; I'm just not convinced yet.
If the problem is "I want to know I can always pass these values in to
create an object", then your solution shouldn't be "Use reflection and
enforce constructors", it should be "Use a parameterized factory".
Same goes for enforcing static method existance. You really should
separate that out into its own class:
public interface SpecialFactory<T extends SpecialObject> {
T createEmpty();
T createFromFoo(Foo foo);
}
Now, you have no reflective games to play, and your compiler will
enforce better behavior.
Reflection does have its place, but there are a lot of very useful
things you can do without it.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>