Reputation: 1454
What is the real reason that in Java, and similar languages, must be explicitly said that a class implements an interface?
Imagine implicit implementation:
interface Flyer { void fly(); }
public class Duck { public void fly() {...} }
public class Plane { public void fly() {...} }
public class Hoe { void hangAround() {...} }
void startFlying(Flyer flyer) {...}
void race() {
...
startFlying(duck); // OK
startFlying(plane); // OK
startFlying(hoe); // Compilation error.
}
Compiler knows method's signatures, return type (and modifier, of course). At this point it seems clear that there is no need to explicitly specify that Duck and Plane implements Flyer.
I would said that "implements XYZ" may be removed from Java without worries.
No difference, check at compilation time so it's OK.
In the other hand: @JBNizet mentioned different meaning of methods with the same signature and return type.
I will use his example:
interface Runner { void run(); }
public class Guy { public void run(); }
public class Gal { public void run(); }
void startRunning(Runner r) {...}
void race() {
startRunning(guy); // OK
startRunning(gal); // OK
startRunning(runnableThread); // OK
}
OK for compiler, OK for startRunning() (OK for me). It's up to your philosophy if this is OK for you or not.
Explicit:
public class Guy **implements Runner **{ public void run(); }
public class Gal **implements Runner **{ public void run(); }
In bold (or text between ** and **) is the price which you must pay for
void race() {
startRunning(guy); // OK
startRunning(gal); // OK
startRunning(runnableThread); // Compilation error!
}
Note compilation error so you can see the issue before testing.
If it's intended to use runnableThread in startRunning() as well you must do it even more explicitly (enough time to realize what you are doing).
"I wondered how much of time is wasted by resolving issues related to typing "implements XYZ" compared to time wasted by resolving issues with implicitly implemented interfaces. If it's way more better for implicitly implemented interface then I hate Java designers for their decision and that they force us to belive it's better :-)"
Ladybug and airbus (and duck)
I think the issue with implicitly implemented interface is only theoretical and rare in real.
public class Airbus {
void takeOff() {...}
void land() {...}
Passenger[] getPassengers() {...}
}
public class Ladybug {
void takeOff() {...}
void land() {...}
}
public class Duck {
void takeOff() {...}
void land() {...}
Passenger[] getPassengers() {...}
}
public interface Aircraft {
void takeOff();
void land();
Passenger[] getPassengers();
}
public void fly(Aircraft aircraft) {
aircraft.takeOff();
for (Passenger p : aircraft.getPassengers()) {...}
aircraft.land();
}
public void airport() {
fly(airbus_a380); // OK
fly(ladybug); // Compilation error, does not match Aircraft requirements.
fly(duck); // OK
}
public interface Lander {
void land();
}
public void landAtMeadow(Lander lander) {...}
public void meadow() {
landAtMeadow(airbus_a380); // OK
landAtMeadow(duck); // OK
landAtMeadow(ladybug); // OK
}
All of them are matching requirements of landAtMeadow so they can be used in that context. Even it may not be possible to land at meadow for airbus_a380 (In other word testing is required) you need to land there in emergency.
Do not forget that landAtMeadow() may have more specific requirements like
public interface Lander { void landAtLimitedArea(int size); }
to say that the space is limited, so if airbus_a380 does not support this method then you have compilation error here.
Upvotes: 0
Views: 209
Reputation: 2672
When a class is declared to implement an interface X then any other method working with interface X is sure that all the necessary methods are implemented in the class (and therefore they do not need to check every time if needed method is implemented). If there was no such declaration, then any method using classes which implement X would need to:
ensure that the class of object whith which the method is working implements all methods necessary (so go through all the methods of the class searching the ones you want every time you expect to work with interface X - instead of doing this once, at compilation).
have many error handling lines of code implemented (what to do, if I expect method A to do something, but method A it is not there at all?)
Static typing adds much to code's safety in general, as many errors are possible to detect at compilation. Why try to change Java from staticaly to dynamicaly typed? There are many dynamicaly typed languages out there, with their pluses and minuses, ready to use (Python, for example).
Upvotes: 0
Reputation: 8058
As others have said, this is a basic characteristic of the Java language. It's there for good reasons, folks who are doing serious largescale programming like it, and there's absolutely no reason to change it.
If it bothers you, I strongly recommend that you find another language that is more weakly typed and use that instead. There are a fair number of languages these days which can be compiled into Java bytecodes and used in a Java environment, so you might not even have to give up the flexibility of being able to run in a JVM.
Upvotes: 1
Reputation: 1717
My friend In a strongly typed languages, for ex: in C or Java, when a variable or reference is declared, it must be informed to the compiler what data type the variable or reference is of
Upvotes: 0
Reputation: 10725
Java is a strong typed language, so the assignation of an instance to an interface typed variable must be validated at compile time. This can only be done by explicitly declared interface implementations.
Upvotes: 5