Consider an example (which compiles in java)
public abstract interface Interface {
public void interfacing();
public abstract boolean interfacing(boolean really);
}
Why is it necessary for an interface to be "declared" abstract? Is there other rules that applies with an abstract interface?
Finally: If abstract is obsolete, why is it included in Java? Is there a history for abstract interface?
Why is it necessary for an interface to be "declared" abstract?
It's not.
public abstract interface Interface {
\___.__/
|
'----> Neither this...
public void interfacing();
public abstract boolean interfacing(boolean really);
\___.__/
|
'----> nor this, are necessary.
}
Interfaces and their methods are implicitly abstract and adding that modifier makes no difference.
Is there other rules that applies with an abstract interface?
No, same rules apply. The method must be implemented by any (concrete) implementing class.
If abstract is obsolete, why is it included in Java? Is there a history for abstract interface?
Interesting question. I dug up the first edition of JLS, and even there it says "This modifier is obsolete and should not be used in new Java programs".
Okay, digging even further... After hitting numerous broken links, I managed to find a copy of the original Oak 0.2 Specification (or "manual"). Quite interesting read I must say, and only 38 pages in total! :-)
Under Section 5, Interfaces, it provides the following example:
public interface Storing {
void freezeDry(Stream s) = 0;
void reconstitute(Stream s) = 0;
}
And in the margin it says
In the future, the " =0" part of declaring methods in interfaces may go away.
Assuming =0 got replaced by the abstract keyword, I suspect that abstract was at some point mandatory for interface methods!
Related article: Java: Abstract interfaces and abstract interface methods
It's not necessary, it's optional, just as public on interface methods.
See the JLS on this:
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html
9.1.1.1 abstract Interfaces Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs.
And
9.4 Abstract Method Declarations
[...]
For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces.
It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods.
It is not necessary to declare the interface abstract.
Just like declaring all those methods public (which they already are if the interface is public) or abstract (which they already are in an interface) is redundant.
No one is stopping you, though.
Other things you can explicitly state, but don't need to:
extends ObjectIs there other rules that applies with an abstract interface?
An interface is already "abstract". Applying that keyword again makes absolutely no difference.
Be aware that in Spring it has non academic meaning.
The abstract interface is a warning to the developer not to use it for @Autowired.
I hope that spring/eclipse @Autowired will look at this attribute and warn/fail about usages of such.
A real example: @Service proxy under @Transnational to a @Repository need to use same basic methods however they should use different interfaces that extends this abstract interface due to @Autowired.
(I call this XXXSpec interface)
Every interface is implicitly abstract.
This modifier is obsolete and should not be used in new programs.
[The Java Language Specification - 9.1.1.1 abstract Interfaces]
Also note that interface member methods are implicitly public abstract.
[The Java Language Specification - 9.2 Interface Members]
Why are those modifiers implicit? There is no other modifier (not even the 'no modifier'-modifier) that would be useful here, so you don't explicitly have to type it.
It's not necessary, as interfaces are by default abstract as all the methods in an interface are abstract.
An abstract Interface is not as redundant as everyone seems to be saying, in theory at least.
An Interface can be extended, just as a Class can. If you design an Interface hierarchy for your application you may well have a 'Base' Interface, you extend other Interfaces from but do not want as an Object in itself.
Example:
public abstract interface MyBaseInterface {
public String getName();
}
public interface MyBoat extends MyBaseInterface {
public String getMastSize();
}
public interface MyDog extends MyBaseInterface {
public long tinsOfFoodPerDay();
}
You do not want a Class to implement the MyBaseInterface, only the other two, MMyDog and MyBoat, but both interfaces share the MyBaseInterface interface, so have a 'name' property.
I know its kinda academic, but I thought some might find it interesting. :-)
It is really just a 'marker' in this case, to signal to implementors of the interface it wasn't designed to be implemented on its own. I should point out a compiler (At least the sun/ora 1.6 I tried it with) compiles a class that implements an abstract interface.
Well 'Abstract Interface' is a Lexical construct: http://en.wikipedia.org/wiki/Lexical_analysis.
It is required by the compiler, you could also write interface.
Well don't get too much into Lexical construct of the language as they might have put it there to resolve some compilation ambiguity which is termed as special cases during compiling process or for some backward compatibility, try to focus on core Lexical construct.
The essence of `interface is to capture some abstract concept (idea/thought/higher order thinking etc) whose implementation may vary ... that is, there may be multiple implementation.
An Interface is a pure abstract data type that represents the features of the Object it is capturing or representing.
Features can be represented by space or by time. When they are represented by space (memory storage) it means that your concrete class will implement a field and method/methods that will operate on that field or by time which means that the task of implementing the feature is purely computational (requires more cpu clocks for processing) so you have a trade off between space and time for feature implementation.
If your concrete class does not implement all features it again becomes abstract because you have a implementation of your thought or idea or abstractness but it is not complete , you specify it by abstract class.
A concrete class will be a class/set of classes which will fully capture the abstractness you are trying to capture class XYZ.
So the Pattern is
Interface--->Abstract class/Abstract classes(depends)-->Concrete class
