why fields are constant in Interfces?

[Bk Jacky]

Hi,

Why fields are static and final in interfaces?Why interface architecture like so?

[Rob Spoor]

Because an interface only describes functionality, not state. A non-constant variable is part of the state of an object (or class, when static). As an interface does not describe the object state, it would be meaningless to have non-constants in it.

[npk chowdary]

I think you know we cannot create object for an Interface.we can create object for implementors .Think like this, static variables can be accessed by reference ok.so this copy is available for all objects implementing those interfaces.If from one object value changes then other can access that value(change) this will lead to messy,so we place final

[Raghavan Muthu]

Howdy B Singh,

Welcome to JavaRanch

First thing you got to update is your display name. Ranch is a very friendly forum which has very less strict policies and one among them is the
display name. Please have a look at this page. You can update your name by editing your profile.

[shibaram sahoo]

I have also a similar kind of confusion in my mind..
Please help me out..

Interface is a contract. (I agree)
Interface are means to be used to create generic behaviours (methods) and attributes (variables), so that implementor classes will get through inheritance. (I agree and believe on this)

But my confusion is that, If I my classes gonna get an attribute from an interface, then I can not modify it as per my class requirement.

[B]interface MyCars{
  public static final String carColor = "BLACK";
}
 
class Car1{
     // carColor = "BLUE"      I can not use this, its restricting me to get         //my favourite color for the car
}
 
class Car1{
   // carColor = "RED"      I can not use this, its restricting me to get           //my favourite color for the car
}[/B]

So why do have all the variables are by default public static final ?
Isn't it would have better like if just public / protected variables (no static)

Then I could have easily get the color through inheritance and whenever I want to change color of my car I could have done that easily..

what do you say..

why do have all the variables are by default public static final, then ?

[Jeanne Boyarsky]

Shibaram,
You could write a getColor() method and have your subclasses implement that. If you want to provide a default implementation, maybe you need an abstract class and not an interface.

Also, "public class MyClass implements MyInterface" is an anti-pattern for inheriting constants. Interfaces are meant to inherit methods or references constants statically. In Java 5+ you can even use static imports to avoid referring to the "constants interface" all over.

[Mike Simmons]

[Jeanne]:Also, "public class MyClass implements MyInterface" is an anti-pattern for inheriting constants.

Well, not quite. It's an anti-pattern if the constants are only inherited for internal use, because those constants become part of the public API. It's not an anti-pattern if the constants are intended to be part of the public API. The best example I know of in the standard libraries are WindowConstants and SwingConstants. You're supposed to see DISPOSE_IN_CLOSE and such when you look at the public API of a JFrame - you use that constant from outside the class. That's fine. It's when you expose purely internal details that constant interfaces are an anti-pattern.

I admit, I shudder a bit when I hold up something in Swing as an example of good design. And in the modern age (JDK 5+), all the examples I can think of for a valid constant interface pattern would probably be better implemented using enums. But remember these were not available when Swing was designed, and the Typesafe Enumeration pattern was not generally known (if it was known at all). So while I may well have doe other things differently, I believe that the use of constant interfaces in WindowConstants and SwingConstants is perfectly valid.

I suspect this is far from shibaram sahoo's original question. That has already been addressed pretty well - but I would add this: why do you think this sort of functionality should be in an interface, anyway? You could simply create a superclass, perhaps an abstract superclass, to include whatever behaviors you want. Of course you can only extend one class in Java - but if that is your objection, then your question is really: why doesn't Java allow multiple inheritance of implementations? This is another FAQ I think. You could probably find many previous discussions of this issue using the Search of FAQ links provided by the forum. I'll skip that though, since I don't even know if that is really your question.
[ August 29, 2008: Message edited by: Mike Simmons ]

[Jeanne Boyarsky]

Originally posted by Mike Simmons:
Well, not quite. It's an anti-pattern if the constants are only inherited for internal use, because those constants become part of the public API. It's not an anti-pattern if the constants are intended to be part of the public API.

That's a good point about the public API.