• Post Reply Bookmark Topic Watch Topic
  • New Topic

variable in interface  RSS feed

 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm just wondering why variables in interface can't be instance scope?

and then


Yes, it violates OO, but I don't see why this is not possible?
in many forums, they say that since interface is not an implementation, therefore it can;t have any instance scope variable. I can;t find the correlation of interface being abstract and being able to hold instance scope variable. There's gotta be another reason. I'm just curious about any programmatic limitation, not deliberate design constraint. the example of programmatic limitation is like when Java forbids multiple inheritance since when different parents have the exact same method, then the child will have trouble determining which method to run at runtime.
thanks
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Spades wrote:Yes, it violates OO, but I don't see why this is not possible?

I suspect you've just answered your own question.

If it violates OO, then why would an OO language allow it?

A better question might be: Why does it violate OO? And the answer to that is that interfaces define a public API. Therefore, any variable you define will be public and, take it from me, public variables are just plain BAD.

Therefore (I assume), the designers decided that any "variable" you define is, in fact, a public constant - ie, it is public, static and - most importantly - final.

Winston
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
so, basically it's just deliberate design constraint? because Java still allows us to declare public instance variables, following that practice, why not allow declaring non static variables in interface? thanks
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would you even want to do this?
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
let me rephrase that question, obviously you wouldn't know why Sun engineers made the interface to behave like that since I'm assuming that you're not part of engineer team involved in creating Java. the question is, what are the problems caused by allowing non static variables in interface other than principle violation?
I'm raking my brain for programmatic limitation like why it's not allowed to use super when loading items from generic collection. thanks
 
Stephan van Hulst
Saloon Keeper
Posts: 7969
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Simply because there's no need. Why add something to a language if you can't think of a scenario in which it would be useful?

As for generic collections, I'm assuming you are referring to that you can't do the following:
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Spades wrote:The question is, what are the problems caused by allowing non static variables in interface other than principle violation?

Well, that right there sounds like a good starter.

Principles don't just grow on trees, they're there for a reason and - I ask again - why on earth would an OO language allow you to break OO principles unless it's unavoidable?

Personally, I would have been quite happy for the compiler to disallow public variables (ie, a public field that does not include the final qualifier) anywhere, because it would have disallowed monstrosities like java.awt.Point (←click). But perhaps, 25 years ago, when the language was being written, the designers had more important things to think about.

Or perhaps they didn't understand the consequences of allowing them. Josh Bloch freely admits that he didn't understand all the ramifications of not making classes final when they should be; and he was one of the foundation designers.
The fact is that almost any book on OO programming will tell you the same thing: public variables are BAD.

Now, if you're asking why public variables in general are a bad thing, that's something different; and the reason is that it allows external entities to update the state of your object, which violates the principles of single responsibility and encapsulation. The ONLY thing that should be able to update an object's state is the object itself; otherwise you're in for a whole heap of pain.

Just as a simple example: Without changing the language, it is impossible to provide guaranteed synchronization for a public variable.

You might also find the DontSweatIt page worth reading (particularly the last topic).

I'm raking my brain for programmatic limitation like why it's not allowed to use super when loading items from generic collection. thanks

I'm afraid you'll have to explain that one to me, because I don't follow.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 7969
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:Personally, I would have been quite happy for the compiler to disallow public variables (ie, a public field that does not include the final qualifier) anywhere, because it would have disallowed monstrosities like java.awt.Point (←click).


Note that in item 14 of the second edition of Effective Java, Joshua Bloch states that there's nothing wrong with visible variables in package private or private classes. Of course, their visibility would effectively never be greater than package private, but there you have it :P
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Note that in item 14 of the second edition of Effective Java, Joshua Bloch states that there's nothing wrong with visible variables in package private or private classes. Of course, their visibility would effectively never be greater than package private, but there you have it :P

True. The same would also be true of nested classes; but since, in either case, "visibility" can be achieved without the public qualifier, I stand by my statement.

Winston
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!