• Post Reply Bookmark Topic Watch Topic
  • New Topic

Interfaces can talk  RSS feed

 
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking about it and I feel there is a strange loophole in the Java language. By definition, an interface is a strictly flat structure with absolutely no executable code(apart from constants). Hence, method calls should not be allowed, and should have no executable code.
But if you consider the bad design below

You are actually calling the constructor from the interface. What is more weird is that you could add runtime variables at that time, and even change the structure of the object.
I know the code sample is a very poor design, but I thought java would address these issues to make it foolproof. Furthermore, if we do


we face the dreaded diamond inheritance problem which was so dreaded in C++
Java doesnt let you compile the code, but I thought interface rules were brought to avoid such problems in the first place.
 
Marshal
Posts: 56610
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If it won't compile, what is the problem?
 
Gaurav Raje
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:If it won't compile, what is the problem?

They could have supported multiple inheritance in the first place and not let the special cases containing diamond inheritance compile. While it is not a good practice, it has the same side effects as the above 1.
 
Gaurav Raje
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Furthermore, the only place where the compiler complains is when I make the ambigous call to t.t.something(). Not if I dont refer the t.t . Not when I instantiate the aer object. Nor when I write the classes with ambigous objects. Which I believe is wrong. At least in multiple inheritance it complains right at the beginning.
 
Campbell Ritchie
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I see what you mean. It compiles nicely until you actually use the collision of t.t
I know you are allowed two methods with the same signature (and return type) in two interfaces, whereas here it doesn't notice there are two identical constant identifiers until you try to use them.

I think you are going to have to go through the Java™ Language Specification; maybe this page will help.
 
Gaurav Raje
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read through that... and apparently, the code is perfectly valid as per the spec(which is reflected in the compile process). I guess (and strictly my opinion) since the code is a little stupid, Java never bothered to address such issues.
 
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gaurav Raje wrote:I read through that... and apparently, the code is perfectly valid as per the spec(which is reflected in the compile process). I guess (and strictly my opinion) since the code is a little stupid, Java never bothered to address such issues.


since both are same one is shadowing the other, since it is legal you don't get any compiler or runtime errors
 
Campbell Ritchie
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The behaviour you are showing is consistent with what it says in that JLS link. If you don't use the shadowing/colliding fields, all is well. You only get an ambiguity if you try to use them without disambiguating them.
 
Gaurav Raje
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree completely. It is perfectly legal and hence the compilation. But my point is, being as strict about object orientation as it is, things like this are not supposed to be allowed. For eg, the inner complications of the superclass class should be taken care of by the same class and not exposed to the end user of the class. What if the superclass which had shadowed variables was used in another method which relied on the t.t object. As per abstraction, if t.t is a valid field in the class, it should anc can be used.
 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gaurav Raje wrote:I agree completely. It is perfectly legal and hence the compilation. But my point is, being as strict about object orientation as it is, things like this are not supposed to be allowed. For eg, the inner complications of the superclass class should be taken care of by the same class and not exposed to the end user of the class. What if the superclass which had shadowed variables was used in another method which relied on the t.t object. As per abstraction, if t.t is a valid field in the class, it should anc can be used.


Can you tell me what is the thing that you think is bypassing the OOPS here in the code. Can you please write your questions one by one
 
Greenhorn
Posts: 10
Chrome Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are missing the point of interfaces ...

The above shows you why the comiler compiles even when you implement the same method multiple times.
The real question is, why are you defining interfaces, if you call the method from the aer class directly anyway ?
 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tom mmeke wrote:You are missing the point of interfaces ...

The above shows you why the comiler compiles even when you implement the same method multiple times.
The real question is, why are you defining interfaces, if you call the method from the aer class directly anyway ?


I thik he is trying to bypass the Java specifications? may i know is it correct?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!