Variables in Interface

Question

Why is that a variable used in an Interface is PUBLIC STATIC FINAL? Why "static" in particular?

I read in a book a while back that it is better to make a variable of an interface like such myInterface myVarible = new myInterface(); than to use a class because it is easier to maintain down the road. How would this be the case. — Doug Hauf, Jan 21 '14 at 15:34
Possible duplicate of [Why are interface variables static and final by default?](http://stackoverflow.com/questions/2430756/why-are-interface-variables-static-and-final-by-default) — Line, May 16 '17 at 13:29

Jon Skeet · Accepted Answer · 2009-12-07T07:32:21.733

24

A field declared in an interface can only be a constant anyway, so why would it depend on which instance you use to access it?

Putting fields in interfaces is often poor style anyway these days. The interface is meant to reflect the capabilities of classes that implement it - which is completely orthogonal to the idea of a constant. It's certainly a nasty idea to use an interface just to declare a bunch of constants. I do occasionally find it useful to make the interface type expose constants which are simple implementations - so a filtering interface might have "ALLOW_ALL" and "ALLOW_NONE" fields, for example.

I suppose you could conceive of a scenario where implementing an interface did actually add an instance field to your class - but that would break encapsulation not only in terms of it being implicitly public, but also by specifying part of the implementation instead of the API.

edited Dec 07 '09 at 07:32

answered Dec 07 '09 at 07:27

Jon Skeet

1,421,763
867
9,128
9,194

3

Static constant parameters are bad as a whole anyway nowadays, replacing bunch of constants with Enums is the proper Java way currently, since it's extremely typesafe, works with switches and can be coded to include multiple (helpful) values to one constant essentially avoiding repetitive magic numbers. – Esko Dec 07 '09 at 08:58
@Jon Skeet Great.. But I wasn't implementing it practically! – Sandeep Dec 07 '09 at 09:33
1

@Esko: Enums are appropriate in *some* cases, but they certainly don't cover *every* case where you'd want constants. In particular, enums are only appropriate where there's a fixed set of values. For example, it would be nice to have Charset "constants" for UTF-8 and the other guaranteed Charsets - but you wouldn't want to make that an enum. Don't try to make everything look like a nail just because you've got the enum hammer :) – Jon Skeet Dec 07 '09 at 09:36
That's mostly because charsets generally aren't static nor constant if you consider their behaviour :) I'm very willing to bet that if something's truly constant as a concept, it can easily be replaced with an enum. – Esko Dec 07 '09 at 10:12
I found that in case of business logic, it's better to stick the constants in the DB and load them up at startup using JPA, i.e., in a pojo. – Giovanni Botta Jan 31 '15 at 18:48
Disagree that having non-static, non-constant variables in interface is a bad thing. Traits in Scala is a good example how to create simple isolated pieces of functionality which could be combined later in one class. – kirhgoff Nov 24 '15 at 08:08
@kirhgoff: This question isn't about Scala though, it's about Java - and my assertion that putting fields in interfaces is poor style is referring to that specific context. Lots of statements that are true for one language become nonsense when applied to a different language. – Jon Skeet Nov 24 '15 at 08:10

fastcodejava · Answer 2 · 2009-12-07T07:32:11.393

6

Because you can not instantiate an interface. Also there cannot be any method body to use a non-static non-final variable.

edited Dec 07 '09 at 07:32

answered Dec 07 '09 at 07:26

fastcodejava

39,895
28
133
186

score 3 · Answer 3 · answered Dec 07 '09 at 07:26

3

Why wouldn't it be static?

It's a constant associated with the interface, rather than with any particular instance of it.

answered Dec 07 '09 at 07:26

Anon.

58,739
8
81
86

abstract class can have instance? – Asif Mushtaq Feb 23 '16 at 16:39

score 3 · Answer 4 · answered Dec 07 '09 at 07:39

The main reason I guess is implementation detail of the VM/language.

If an interface is not allowed to have non-static variables, there's no need to allocate memory for the interface during the creation of the class. There's also no need for special naming/renaming mechanisms in case you inherit variables with the same name. The only thing you need is some table to call the correct functions when the interface is used.

In short - it makes the live of the language / VM maintainer easier. If you really want to take a look at multiple inheritance and its pitfalls and traps, read Object Oriented Software Construction by Bertrand Meyer (2nd Edition). Then you understand why the interface needs to be so simple (and yet archives most of the things multiple inheritance does).

score 2 · Answer 5 · answered Jan 31 '15 at 18:42

An interface is a contract that defines the interaction between objects.

This interaction is defined by the exposed methods, not by the variables. Variables would only describe the internal working, not the interaction.

Note that variables should never be used for interaction. According to the OOP principle of encapsulation, it would be a crime to let 1 class access a variable of another class directly.

Constants (e.g.Math.PI) are the only acceptable exception. Since constants are the only kind of variables that can be accessed directly by other classes without violating the principle of encapsulation, all variables in an interface are treated as public static final variables (i.e. constants)

Variables in Interface

5 Answers5

Linked