a lot of good points.
I think my "why not?" question was really asking
"why not in theory". After all, if we view the interface
as providing a "behavioral contract" with the implementing
class, then it doesn't seem at all odd to me to specify behavior
for a Constructor.
Maybe it's a 'grey area' about what constitutes implementation
versus behavior, though. I mean, why isn't it behavior to say
"this class should be able to create an instance of itself given this information"?
Your response seems to be saying that we shouldn't specify (and we can't in Java)
the information flowing into the class to create an instance, but we can
specify the information flowing into the instance (through the accessors
defined in the interface). Which seems like one place to draw the line,
but maybe not the only one.
Also thanks for the suggestion of the Abstract class. I guess if
I had a lot of constructors, or complex constructors, or constructors
needing information at runtime I would also consider a Factory
class to create my instances (it could even implement a Factory
interface to define that behavioral contract :).
Thanks again,
At 09:19 AM 10/11/2004, you wrote:
> -----Original Message-----
> From: Thomas Hicks [mailto:[EMAIL PROTECTED]]
>
> 1) Is it true that an Interface cannot specify Constructor behavior?
Yes. In a quick scan of the JLS I could not find the restriction stated explicitly, but it is implied by the formal grammar for an
interface in section 9.1.3 (http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#236431). An interface may
declare constants, abstract methods, classes and interfaces. Constructors are not mentioned.
> 2) Why not?
An interface doesn't need a constructor because it does not declare something that can be constructed. It only defines a set of
behaviors that some set of classes may agree to provide. The details of how they provide that behavior is none of the interface's
business. You can't write
Country c = new Country("USA", "United States");
because Country can't be instantiated in its own right; you have to instantiate a class that implements Country. And it's up to
that class to decide what its constructor looks like as well as how it knows what Country it's associated with.
At least in part, this restriction flows from the decision made by Java's designers to avoid C++-style multiple inheritance. We
have multiple inheritance of interface but only single inheritance of implementation. If you put a constructor into an interface,
you are specifying an implementation detail: the information required to create an instance.
Consider your 'Country' interface. Methods that return the country name and ISO code are perfectly reasonable since those are
things any class implementing Country should be able to provide. But if you specify a constructor as well then your interface is
meddling in the definition of where the information comes from, and that is an implementation detail that properly belongs to the
class implementing Country.
You may be thinking that any class implementing Country will need to be told what country a given instance represents. But suppose
I wrote the following class:
public class PointOnEarth implements Country {
public PointOnEarth(float latitude, float longitude) { ... }
public String getCode() { ... }
public String getName() { ... }
}
Assuming the presence of a really good GIS :-), this class implements the Country interface without needing to have the country
specified either at construction or any other time. So what would we do with the Country constructor if there was one? All that
Country should be concerned with is that an instance of it can identify what country it represents, and not how it knows that.
> p.s. What I have in mind is something like the following:
Depending on what you really want to accomplish, an abstract base class may be more appropriate than an interface. That approach
does allow you to specify construction-time requirements, since any subclass constructor is required to invoke one of its
superclass's constructors.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
