Subclasses in interfaces

[Bura Tino]

Hi,

Why is this the following structure prohibited?

public interface SomeInterface {

public int getNumber();


public class SomeClass {
public boolean isSame(int i) { return i == getNumber(); }
}
}

non-static method getNumber() cannot be referenced from a static
context at line 9 (9:48)

Thanks!

Bura

 

[Chris Smith]

Why is this the following structure prohibited?

public interface SomeInterface {

public int getNumber();


public class SomeClass {
public boolean isSame(int i) { return i == getNumber(); }
}
}

non-static method getNumber() cannot be referenced from a static
context at line 9 (9:48)

It's because interfaces may not contain inner classes. Therefore, all
classes declared inside of an interface are inherently static nested
classes, which have no implicit reference to a containing instance. As
for the justfication for prohibiting interfaces from containing inner
classes, it could be lots of things. The reason that makes the most
sense to me is that inner classes are a low-level implementation tool,
the use of which should be hidden from client code. That contradicts
the basic purpose of an interface.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas G. Marshall]

It's because interfaces may not contain inner classes. Therefore, all
classes declared inside of an interface are inherently static nested
classes, which have no implicit reference to a containing instance.
As for the justfication for prohibiting interfaces from containing
inner classes, it could be lots of things. The reason that makes the
most sense to me is that inner classes are a low-level implementation
tool, the use of which should be hidden from client code. That
contradicts the basic purpose of an interface.

Yep, or to further your point, it contradicts the basic purpose of an
interface because an interface's role is to establish a contract, not
provide the implementation for satisfying a contract.

On a 10% related note, I loath the ability to put static values within the
interface for purposes of accessing them anywhere downwind the hierarchy
fully unqualified.

Gross.

 

[A. Craig West]

On a 10% related note, I loath the ability to put static values within the
interface for purposes of accessing them anywhere downwind the hierarchy
fully unqualified.

I believe that the reason static values are allowed in interfaces is because
Java (originally, at least) is lacking enum types. You can't specify what
values are legal for an int argument to a method, but you can at least give
reasonably well-named values which are acceptable. For example, an interface:
interface Sortable {
public static final int COLLATE_ASCENDING = 0;
public static final int COLLATE_DESCENDING = 1;
public void sort(int collationOrder);
}

Admittedly, this is only useful if it includes javadocs specifying that the
allowable values for collationOrder are CALLATE_ASCENDING and
COLLATE_DESCENDING, but it's something. Now if we include proper enum types,
this isn't necessary...

 

[Bura Tino]

Yep, or to further your point, it contradicts the basic purpose of an
interface because an interface's role is to establish a contract, not
provide the implementation for satisfying a contract.

On a 10% related note, I loath the ability to put static values within the
interface for purposes of accessing them anywhere downwind the hierarchy
fully unqualified.

Gross.

I respectfully disagree. I'm not specifying an implementation of
getNumber(). All I am trying to achieve is good namespace management.
I believe that some classes belong inside interfaces.

For example,

public interface SomePeculiarListClass {

public class Iterator {
// Would be nice to take advantage of the implicit pointer to the
list
}
}


Also, named constant definitely belong in interfaces.

public interface SomePeculiarFileRead {
public static final int EOF = -1;
}

Where else would you put it?

Anyway, I accept the limitation of java, but still looking for a way
to manage my namespace well.

Bura

 

[Dale King]

Yep, or to further your point, it contradicts the basic purpose of an
interface because an interface's role is to establish a contract, not
provide the implementation for satisfying a contract.

I disagree. There is nothing wrong with classes being defined within the
interface and I find it a very effective technique for defining enumeration
type values and the interface sort of serves as namespace. Here is a trivial
example:

public interface Constant
{
String getName();
double getValue();

private static class Implementation implements Constant
{
private double value;
private String name;
private Implementation( String name, double value )
{
this.name = name;
this.value = value;
}
public double getName()
{
return name;
}
public double getValue()
{
return value;
}
}

Constant meaningOfLife = new Constant( "The meaning of life", 42 );
Constant pi = new Constant( "Pi", Math.PI );
}

On a 10% related note, I loath the ability to put static values within the
interface for purposes of accessing them anywhere downwind the hierarchy
fully unqualified.

The need for doing that will go away in 1.5 with the inclusion of static
import, but I do not find the practice that loathsome.

 

[Thomas G. Marshall]

"Thomas G. Marshall"


I respectfully disagree. I'm not specifying an implementation of
getNumber(). All I am trying to achieve is good namespace management.
I believe that some classes belong inside interfaces.

For example,

public interface SomePeculiarListClass {

public class Iterator {
// Would be nice to take advantage of the implicit pointer to the
list
}
}

IMHO, that does not specify a contract in the terms you are thinking.

Also, named constant definitely belong in interfaces.

public interface SomePeculiarFileRead {
public static final int EOF = -1;
}

Where else would you put it?

public class InputConstants
{
public static final int EOF = -1;
}

And of course, since they are /public static final/, the value is still
substituted in AS AN IMMEDIATE at compile time, so you lose nothing in terms
of execution speed, and only gain readability and maintainability.

I've had to search up and down for rogue constants supplied in an interface
that was somewhere up the hierarchy chain in the middle of nowhere.
Allowing a constant that is not easily identifiable is a huge mistake.

 

[Thomas G. Marshall]

"Thomas G. Marshall"


I disagree. There is nothing wrong with classes being defined within
the interface and I find it a very effective technique for defining
enumeration type values and the interface sort of serves as
namespace. Here is a trivial example:

public interface Constant
{
String getName();
double getValue();

private static class Implementation implements Constant
{
private double value;
private String name;
private Implementation( String name, double value )
{
this.name = name;
this.value = value;
}
public double getName()
{
return name;
}
public double getValue()
{
return value;
}
}

Constant meaningOfLife = new Constant( "The meaning of life", 42
); Constant pi = new Constant( "Pi", Math.PI );
}


The need for doing that will go away in 1.5 with the inclusion of
static import, but I do not find the practice that loathsome.

Fair enough. Agree to disagree.

 

[Thomas G. Marshall]

Thomas G. Marshall


I believe that the reason static values are allowed in interfaces is
because Java (originally, at least) is lacking enum types. You can't
specify what values are legal for an int argument to a method, but
you can at least give reasonably well-named values which are
acceptable. For example, an interface: interface Sortable {
public static final int COLLATE_ASCENDING = 0;
public static final int COLLATE_DESCENDING = 1;
public void sort(int collationOrder);

No. Above all else, such values are not compile-time type-safe!

PRE-1.5:

1. Consider the proper enumeration technique instead (simplest version
which only requires diferentiation of values):

public class SortEnum
{
public SortEnum COLLATE_ASCENDING = new SortEnum();
public SortEnum COLLATE_DESCENDING = new SortEnum();
}

2. Consider the following full blown code, but easy, if what you need are
int values, there are even better versions of this that I use for abitrary
types, but lets keep it simple[r]:

public class SortEnum extends AbstractEnum
{
public SortEnum COLLATE_ASCENDING = new SortEnum(0);
public SortEnum COLLATE_DESCENDING = new SortEnum(1);
}

public abstract class AbstractEnum
{
/** no-argument constructor MUST disallow later calls to getValue() */
protected AbstractEnum()
{
valuesAllowed = false;
} //protected AbstractEnum()


/**
* Extenders of this class MUST call this constructor if they need the
* enums to contain specific values...
*/
protected AbstractEnum(int value)
{
valuesAllowed = true;
this.value = value;

} //protected AbstractEnum(int value)


//------------------------------------------------------------------------


public int getValue()
{
if (! valuesAllowed)
throw new RuntimeException("No values allowed on this ENUM!!!");
return value;
} //public int getValue()


/**
* Returns the string representation of the Enum declaration itself, if
* security restrictions permit.
*
* <p>This works by searching all the fields of this object until one is
* equal to the reference <code>this</code>. Currently this will only
work
* on public static members of public classes. Access restrictions will
* result in the reference not being found, which results in the default
* <code>super.toString()</code> invocation.
*/
public String toString()
{
Class myClass = this.getClass();
Field[] myFields = myClass.getDeclaredFields();

// Look through all memebers looking for one that equals "this"...
for (int i=0; i < myFields.length; i++)
{
try
{
if (myFields.get(null) == this)
return myFields.getName();
}
// If we cannot look at that field, then we ignore the resulting
// exception, and continue looking for "this"...
catch (Exception IllegalAccessException){}
}

// If we got here, then either 1. the field does not exist, which is
// an error condition, or 2. the field exists but had access
// restrictions preventing us from checking its reference value. We
// therefore use the default superclasses String converter...
return super.toString();

} //public String toString()


//------------------------------------------------------------------------

private int value;
private boolean valuesAllowed = false;


//------------------------------------------------------------------------
} //public abstract class AbstractEnum

 

[Dale King]

IMHO, that does not specify a contract in the terms you are thinking.



public class InputConstants
{
public static final int EOF = -1;
}

I get really disgusted when someone says that this "contradicts the basic
purpose of an interface" to use it only to define constants. How does your
class version not contradict the basic purpose of a class?

And of course, since they are /public static final/, the value is still
substituted in AS AN IMMEDIATE at compile time, so you lose nothing in terms
of execution speed, and only gain readability and maintainability.

Technical nitpick, it is not sufficient for a field to be static and final
for its value to be substituted at compile time. It must also be initialized
with a compile-time constant. Interface fields as well as class static final
fields do not have to be initialized with a compile-time constant. I don't
think it has any bearing on the argument either way, but wanted to make sure
we are precise.

I've had to search up and down for rogue constants supplied in an interface
that was somewhere up the hierarchy chain in the middle of nowhere.
Allowing a constant that is not easily identifiable is a huge mistake.

Well, what if I sub-class your InputConstants class to get access to the
constant unqualified? You have the same problem. At least when we get 1.5
the point will be moot.

 

[Thomas G. Marshall]

Dale King <[email protected]> coughed up the following:

....[Thwack]...

I get really disgusted when someone says that this "contradicts the
basic purpose of an interface" to use it only to define constants.
How does your class version not contradict the basic purpose of a
class?

I'm sorry that you get disgusted over this. The point of the class is that
you access the statics in a qualified way. You correctly point out that
subclassing the class allows unqualified access below, which I try to answer
below.

Technical nitpick, it is not sufficient for a field to be static and
final for its value to be substituted at compile time. It must also
be initialized with a compile-time constant.

Of course. Since the example given was of compile time immediate
assignment, I'm not sure why I'd have to go the extra mile to state the
obvious, but sure, ok.

....[thwack]...

Well, what if I sub-class your InputConstants class to get access to
the constant unqualified? You have the same problem.

Yes, but not nearly as likely. There is MI of interfaces, not of classes:
If you inherit from a constants class like I discuss, then you are no longer
able to inherit from any other class in the java hierarchy that you would
need.

At least when we
get 1.5 the point will be moot.

I have been trying to point out that this issue of interface constants is
not the entirety of what enums are about. Enums are compile-time type-safe
constructs, not just ways of holding ints. If not 1.5, then take C++: an
enum element can /evaluate/ to a number, but it is of the enum type when
passing it about. Compile time type-safe.

This current discussion was about using interfaces to hold merely int
values, which is a related, but separate concern, handled better IMHO with
classes.

 

[Chris Smith]

I respectfully disagree. I'm not specifying an implementation of
getNumber(). All I am trying to achieve is good namespace management.
I believe that some classes belong inside interfaces.

For example,

public interface SomePeculiarListClass {

public class Iterator {
// Would be nice to take advantage of the implicit pointer to the
list
}
}

What you've got there is a class whose purpose is to iterate over a
list. That's quite expressible inside of an interface. However, you
are *also* trying to say that this class is an inner class of the list.
It's that part that's not possible, specifically because the interface
is not the place to deal with implementation details like that. Classes
defined in an interface are intended to be exposed to client code; but
as an inner class, your Iterator appears to be intended as a convenience
to the implementor of the interface. If so, write it as a separate
class.

If you insist on including it, you'd write the class to take an instance
of SomePeculiarListClass as a constructor parameter, so that it at least
respects use by client code as an option. Inner classes are intended,
on the other hand, to be created from an instance of their enclosing
class; though a clumsy syntax exists for doing otherwise, it's neither
common nor advisable.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

Dale King <[email protected]> coughed up the following:

...[Thwack]...

I get really disgusted when someone says that this "contradicts the
basic purpose of an interface" to use it only to define constants.
How does your class version not contradict the basic purpose of a
class?

I'm sorry that you get disgusted over this. The point of the class is that
you access the statics in a qualified way. You correctly point out that
subclassing the class allows unqualified access below, which I try to answer
below.

Let me try to restate this. I can understand your objections on a stylistic
basis. Implementing an interface to access constants unqualified is usually
a bad practice and I'm glad that in 1.5 we can just do static import to use
constants unqualifed. And I have no trouble with anyone saying that you
should refrain from doing it that way. But sometimes having to qualify every
single access to every constant can lead to less readable code and requires
more laborious typing.

My problem is when someone tries to dress the argument up and say this
violates the purpose of an interface. And you aren't the only one to do so.

In reality it doesn't contradict the "basic purpose" of an interface. Where
is this basic purpose defined? I can't seem to find a basic purpose for
interfaces called out in the JLS.

It seems to me that an interface has 3 purposes:

To define a reference type
To define an API that implementers must provide implementations for
To define "constants"

It is not a contradiction of the basic purpose to only use it for a subset
of this purposes. For example Serializable and Cloneable only use the first
purpose. Is that a contradiction of the basic purpose of an interface?

I also have trouble when someone says it is wrong to put just constants in
an interface in your client API, because this allows a client to implement
the interface and access the constants. In my opinion, that is an issue for
the client. The fact that I may expose constants in an interface does not
force you to implement the interface.

Some other criticisms that are valid (from the JSR for static import):

"But, inheriting from an interface to get access to
constants in an implementation is a publicly visible operation, and is
therefore
subject to all the rules for binary compatibility when modifying the
constatnts.
Moreover, it requires all other implementations to inherit the same
interface and the same constants,
even though that other implementation may not require them."

Of course. Since the example given was of compile time immediate
assignment, I'm not sure why I'd have to go the extra mile to state the
obvious, but sure, ok.

You were the one that brought up execution speed in terms of choosing one
against the other. I'm only pointing out that it is completely orthogonal to
the entire question. As I said it was a nitpick.

Yes, but not nearly as likely. There is MI of interfaces, not of classes:
If you inherit from a constants class like I discuss, then you are no longer
able to inherit from any other class in the java hierarchy that you would
need.

So what? It is still possible and is likely.

I have been trying to point out that this issue of interface constants is
not the entirety of what enums are about. Enums are compile-time type-safe
constructs, not just ways of holding ints. If not 1.5, then take C++: an
enum element can /evaluate/ to a number, but it is of the enum type when
passing it about. Compile time type-safe.

That's all interesting, but who said anything about enums? I was talking
about static import which is coming in 1.5. See
http://jcp.org/aboutJava/communityprocess/jsr/tiger/static-import.html

This current discussion was about using interfaces to hold merely int
values, which is a related, but separate concern, handled better IMHO with
classes.

But the issue is that it is often undesirably verbose to have to refer to
them using the qualified name every time. When you start having to use a
constant more than once or twice (let's say 20-30 times) it gets really old
to have to qualify it every time. If you have ever done any heavy work with
the Java ByteCode Engineering Library (BCEL) you'd thank your lucky stars
for being able to "implement" the constants interface (See
http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/Constants.html).

Another advantage to declaring constants in an interface is that I don't
have to type the public static final on each of them. I know for certain
that each is unchangeable and that it was explicitly initialized.

There is another alternative to consider here to access constants
unqualified in a class and that is giving them an alias in the class, such
as

class Foo
{
private static final int CONSTANT = Bar.CONSTANT;

Of course this is only viable when using a small number of constants.

But once again the entire argument will be moot in 1.5 with static import.

 

[Thomas G. Marshall]

Dale King <[email protected]> coughed up the following:

....[rip]...

My problem is when someone tries to dress the argument up and say this
violates the purpose of an interface. And you aren't the only one to
do so.

Nor should I be. In OO, an objects interface is the description of the
operations (methods) allowed on the object, as a form of contract, not the
implementation of such operations. I and many others are arguing that
Java's /interface/ should be the same.

In reality it doesn't contradict the "basic purpose" of an interface.
Where is this basic purpose defined? I can't seem to find a basic
purpose for interfaces called out in the JLS.

This is not an issue about /what/ java allows. It's a discussion about
/how/ java should be used in proper design.

The JLS talks about classes, but you cannot find in the JLS about proper OO
design using the various patterns correctly, can you? Does that mean that
there should be no opinion on what is right or wrong?

 

[Dale King]

Dale King <[email protected]> coughed up the following:

...[rip]...

My problem is when someone tries to dress the argument up and say this
violates the purpose of an interface. And you aren't the only one to
do so.

Nor should I be. In OO, an objects interface is the description of the
operations (methods) allowed on the object, as a form of contract, not the
implementation of such operations. I and many others are arguing that
Java's /interface/ should be the same.

And defining constants in an interface in no way contradicts that. Constants
can be part of the interface, since you need to pass those constants to the
interface.

This is not an issue about /what/ java allows. It's a discussion about
/how/ java should be used in proper design.

The JLS talks about classes, but you cannot find in the JLS about proper OO
design using the various patterns correctly, can you? Does that mean that
there should be no opinion on what is right or wrong?

Oh, now it is a discussion. What happened to the rigidly defined "basic
purpose" for an interface?

 

[Thomas G. Marshall]

"Thomas G. Marshall"

Dale King <[email protected]> coughed up the following:

...[rip]...

My problem is when someone tries to dress the argument up and say
this violates the purpose of an interface. And you aren't the only
one to
do so.

Nor should I be. In OO, an objects interface is the description of
the operations (methods) allowed on the object, as a form of
contract, not the implementation of such operations. I and many
others are arguing that Java's /interface/ should be the same.

And defining constants in an interface in no way contradicts that.
Constants can be part of the interface, since you need to pass those
constants to the interface.

You just said it there: "pass those constants TO the interface". They are
separate notions, even though the implementation of the interface may
require a particular set of constants.

Oh, now it is a discussion. What happened to the rigidly defined
"basic purpose" for an interface?

*IT ALWAYS WAS A DISCUSSION*. We are discussing what is /right and wrong/
in engineering, and not what the /jls/ defines. And don't pretend that the
focus has shifted, it never has. And you didn't respond to this point:

The JLS talks about classes, but you cannot find in
the JLS about proper OO design using the various
patterns correctly, can you? Does that mean that
there should be no opinion on what is right or wrong?

Ok, this is enough. We are arguing orthogonal to each other. You are
stating what java allows, and I am stating what /should/ be allowed.
Conversation seems over.

 

[Dale King]

"Thomas G. Marshall"

Dale King <[email protected]> coughed up the following:

...[rip]...

My problem is when someone tries to dress the argument up and say
this violates the purpose of an interface. And you aren't the only
one to
do so.

Nor should I be. In OO, an objects interface is the description of
the operations (methods) allowed on the object, as a form of
contract, not the implementation of such operations. I and many
others are arguing that Java's /interface/ should be the same.

And defining constants in an interface in no way contradicts that.
Constants can be part of the interface, since you need to pass those
constants to the interface.

You just said it there: "pass those constants TO the interface". They are
separate notions, even though the implementation of the interface may
require a particular set of constants.

No the constants are not an implementation detail, they are part of the
interface. If I have an interface and it defines a method that takes one of
several constants, then it is a detail of the interface not just an
implementation detail. Are you claiming that those constants should be
defined separately from the interface? I would disagree with that.

They should be defined with the interface methods that accept them. Take for
example the interface javax.swing.tree.TreeSelectionModel. It defines
several constants which are very much part of the interface and not just an
implementation detail. If you want to control the selection mode of your
tree then you have to know those constants.

It seems to me that defining constants is very much part of the purpose for
an interface.

*IT ALWAYS WAS A DISCUSSION*. We are discussing what is /right and wrong/
in engineering, and not what the /jls/ defines. And don't pretend that the
focus has shifted, it never has.

And you used faulty logic (I would classify it as an appeal to anonymous
authority http://www.datanation.com/fallacies/anon.htm) to in that
discussion when you said it contradicted the "basic purpose" of an
interface.

And you didn't respond to this point:
The JLS talks about classes, but you cannot find in
the JLS about proper OO design using the various
patterns correctly, can you? Does that mean that
there should be no opinion on what is right or wrong?

Because it had nothing to do with the subject at hand, which was, what is
this "basic purpose" of an interface. All I did was point out that I don't
see any basic purpose that was contradicted in the JLS. If you have some
other place that does define this "basic purpose" then I'd be glad to read
it. But it seems to me that you are trying to dress up your stylistic
objections by using some unkown defintion that describes what interfaces are
to be used for.

There should be opinions on what is right and wrong, but not with faulty
logic. There are certainly arguments that can be made against the practice,
but saying it contradicts the basic purpose of an interface does not appear
to be a valid one to me.

Ok, this is enough. We are arguing orthogonal to each other. You are
stating what java allows, and I am stating what /should/ be allowed.
Conversation seems over.

We are arguing orthogonal to each other because you keep refusing to answer
the question and changing the subject.

I am still after the definition of what this "basic purpose" of an interface
is. You said it was somehow violated yet we still do not have any definition
of what that is. I gave 3 purposes for an interface that I see coming from
the defintion of an interface. One of those purposes is obviously to define
constants, so I fail to see how using it for that purpose violates the basic
purpose.

Are you claiming that constants should never be defined in an interface? I
would definitely take issue with that because the constants you pass to the
interface are part of the "interface" which is what I was saying above.

 

[Thomas G. Marshall]

"Thomas G. Marshall"
....[rip]...

*IT ALWAYS WAS A DISCUSSION*. We are discussing what is /right and
wrong/ in engineering, and not what the /jls/ defines. And don't
pretend that the focus has shifted, it never has.

And you used faulty logic (I would classify it as an appeal to
anonymous authority http://www.datanation.com/fallacies/anon.htm) to
in that discussion when you said it contradicted the "basic purpose"
of an interface.

Faulty logic? You've completely botched how this began! The discussion of
the "basic purpose" of an interface was a reuse of the phrase from Chris
Smith, and was regarding *inner classes not constants* ! I made an
additional comment about using them for constants, but claimed that it was
only 10% related! Look:

ChrisSmith:
It's because interfaces may not contain inner classes.
Therefore, all classes declared inside of an interface are
inherently static nested classes, which have no implicit
reference to a containing instance. As for the justfication
for prohibiting interfaces from containing inner classes, it
could be lots of things. The reason that makes the most
sense to me is that inner classes are a low-level implementation
tool, the use of which should be hidden from client code.
That contradicts the basic purpose of an interface.

Me:
Yep, or to further your point, it contradicts the basic
purpose of an interface because an interface's role is
to establish a contract, not provide the implementation
for satisfying a contract.

On a 10% related note, I loath the ability to put static
values within the interface for purposes of accessing
them anywhere downwind the hierarchy fully unqualified.

Gross.

And then several posts later, you quote the above and more, and then respond
to this with:

You:
I get really disgusted when someone says that this
"contradicts the basic purpose of an interface" to use
it only to define constants.

First of all, I said the basic purpose of the interface was contradicted
with inner classes, not with constants. The constants was an additional
note. And it's true: "for purposes of accessing them anywhere downwind the
hierarchy fully unqualified" is indeed gross. But you misplaced the "basic
purpose" phrase.

It is accurate to say that even in the case of interface methods with
specific constants for those methods kept together, I indeed /still/ DON'T
like putting constants into interfaces or under any other circumstances,
because of how they can be accessed unqualified. It's asking for trouble,
and it's trouble I've seen over and over.

We are arguing orthogonal to each other because you keep refusing to answer
the question and changing the subject.

The subject is the same as it was. You reacted to the wrong statements.

....[thwack]...

Are you claiming that constants should never be defined in an interface? I
would definitely take issue with that because the constants you pass to the
interface are part of the "interface" which is what I was saying above.

Less so that than this (again): I am saying that constants should never be
defined in an interface for the purpose (for the sole purpose) of accessing
them unqualified anywhere downwind, which is often the sole reason that
constants are used. javax.swing.SwingConstants for example.
javax.swing.SwingConstants really ought to be a class IMHO.

But yes, as for putting constants into interfaces at all, for any reason,
I'm also against it for the sole reason of the unqualified access issue. To
me constants are a form of data, and data belongs in a class.