接口中的属性/成员变量？

小开

Interfaces cannot require instance variables to be defined -- only methods.

(Variables can be defined in interfaces, but they do not behave as might be expected: they are treated as final static.)

Happy coding.

小开

You can only do this with an abstract class, not with an interface.

Declare Rectangle as an abstract class instead of an interface and declare the methods that must be implemented by the sub-class as public abstract. Then class Tile extends class Rectangle and must implement the abstract methods from Rectangle.

小开

In Java you can't. Interface has to do with methods and signature, it does not have to do with the internal state of an object -- that is an implementation question. And this makes sense too -- I mean, simply because certain attributes exist, it does not mean that they have to be used by the implementing class. getHeight could actually point to the width variable (assuming that the implementer is a sadist).

(As a note -- this is not true of all languages, ActionScript allows for declaration of pseudo attributes, and I believe C# does too)

小开

Fields in interfaces are implicitly public static final. (Also methods are implicitly public, so you can drop the public keyword.) Even if you use an abstract class instead of an interface, I strongly suggest making all non-constant (public static final of a primitive or immutable object reference) private. More generally "prefer composition to inheritance" - a Tile is-not-a Rectangle (of course, you can play word games with "is-a" and "has-a").

小开

最佳答案

The point of an interface is to specify the public API. An interface has no state. Any variables that you create are really constants (so be careful about making mutable objects in interfaces).

Basically an interface says here are all of the methods that a class that implements it must support. It probably would have been better if the creators of Java had not allowed constants in interfaces, but too late to get rid of that now (and there are some cases where constants are sensible in interfaces).

Because you are just specifying what methods have to be implemented there is no idea of state (no instance variables). If you want to require that every class has a certain variable you need to use an abstract class.

Finally, you should, generally speaking, not use public variables, so the idea of putting variables into an interface is a bad idea to begin with.

Short answer - you can't do what you want because it is "wrong" in Java.

Edit:

class Tile
implements Rectangle
{
private int height;
private int width;


@Override
public int getHeight() {
return height;
}


@Override
public int getWidth() {
return width;
}


@Override
public void setHeight(int h) {
height = h;
}


@Override
public void setWidth(int w) {
width = w;
}
}

an alternative version would be:

abstract class AbstractRectangle
implements Rectangle
{
private int height;
private int width;


@Override
public int getHeight() {
return height;
}


@Override
public int getWidth() {
return width;
}


@Override
public void setHeight(int h) {
height = h;
}


@Override
public void setWidth(int w) {
width = w;
}
}


class Tile
extends AbstractRectangle
{
}

小开

Something important has been said by Tom:

if you use the has-a concept, you avoid the issue.

Indeed, if instead of using extends and implements you define two attributes, one of type rectangle, one of type JLabel in your Tile class, then you can define a Rectangle to be either an interface or a class.

Furthermore, I would normally encourage the use of interfaces in connection with has-a, but I guess it would be an overkill in your situation. However, you are the only one that can decide on this point (tradeoff flexibility/over-engineering).

小开

Java 8 introduced default methods for interfaces using which you can body to the methods. According to OOPs interfaces should act as contract between two systems/parties.

But still i found a way to achieve storing properties in the interface. I admit it is kinda ugly implementation.

   import java.util.Map;
import java.util.WeakHashMap;


interface Rectangle
{


class Storage
{
private static final Map<Rectangle, Integer> heightMap = new WeakHashMap<>();
private static final Map<Rectangle, Integer> widthMap = new WeakHashMap<>();
}


default public int getHeight()
{
return Storage.heightMap.get(this);
}


default public int getWidth()
{
return Storage.widthMap.get(this);
}


default public void setHeight(int height)
{
Storage.heightMap.put(this, height);
}


default public void setWidth(int width)
{
Storage.widthMap.put(this, width);
}
}

This interface is ugly. For storing simple property it needed two hashmaps and each hashmap by default creates 16 entries by default. Additionally when real object is dereferenced JVM additionally need to remove this weak reference.

小开

For interfaces with member variables, use an abstract class:

public abstract class Rectangle {
int height = 0;
int width = 0;


public abstract int getHeight();
public abstract int getWidth();
public abstract void setHeight(int height);
public abstract void setWidth(int width);
}

小开

Like everyone says, you cannot add attributes to an interface.

But, I follows this answer: https://stackoverflow.com/a/25907755/12955288 You can use an service with a WeakHashMap to store attributes.

To reduce maps, use a Map of keys like this:

In java 11:

public interface Rectangle {


class Storage {
private static final Map<Rectangle, Map<String, Object>> attributes = new WeakHashMap<>();
}


private Map<String, Object> getAttributes(){
return Storage.attributes.computeIfAbsent(this, k -> new HashMap<>());
}


default public int getHeight() {
return (int) getAttributes().getOrDefault("height", 0);
}


default public int getWidth() {
return (int) getAttributes().getOrDefault("width", 0);
}


default public void setHeight(int height) {
getAttributes().put("height", height);
}


default public void setWidth(int width) {
getAttributes().put("width", width);
}
}

小开

An ancillary point:

I always thought declaring attributes in an interface is sort of an anti-pattern as interfaces are stateless. And I haven't had a practical use case for it until I required dependency injection on all the concrete classes implementing the interface. While I could manually inject the dependencies on each class, it would be easier to inherit them from a parent class.

So, as many people have already mentioned, using an Abstract class is the way to go where the dependency can be injected (@Inject), and all the child classes could extend this and override (@Override) the methods while using the attributes of the parent class.