我知道在Java中不可能使用抽象/重写的静态方法，但我的代码似乎需要它们

Question

I'm sure I'm going about this in the wrong way, but there is a general pattern I want to implement in which instances of a certain class represent elements of a set, and static methods of the class give properties of the set as a whole. I started off with only one class and thus one set, but I want to extend it to similar sets and have generic methods that work for all of them. I was thinking making more classes and having them all extend the same interface, but this would involve the interface specifying static methods and the implementing classes overriding them.

I think the problem might be best explained using Group Theory. For those who don't know, a group is a mathematical object that comprises a set of elements, along with a group operation (represented by *) that combines two elements and returns a third. Among other conditions there must be an identity element e such that a * e = a for all e, and every element a must have an inverse ai such that a * ai = e. The simplest example is the integers where addition is the group operation, the identity element is zero, and the inverse of an element is its negation. If I have a generic class that manipulates elements of a group, there are instances where I would need to know what the identity element of the group is.

So my sample interface for groups might be something like

public interface GroupElement {

    public GroupElement operate(GroupElement element);

    public static GroupElement identity();

}

With the integer implementation being this (ignore the obvious conflict with the preexisting Integer class):

public class Integer implements GroupElement {

    private int i;

    public Integer(int i) {
        this.i = i;
    }

    public Integer operate(Integer other) {
        return new Integer(i + other.i);
    }

    public static Integer identity() {
        return new Integer(0);
    }
}

And then a generic object that checks if one element is the inverse of another:

public class InverseChecker <E implements GroupElement> {

    public boolean isInverse(e element1, e element2) {
        return element1.operate(element2).equals(E.identity());
    }
}

Obviously there is a lot wrong with the above code. The first problem is that I cannot declare a static method in an interface, and even if I used an abstract parent class the child classes could not override the static method. I could make the identity() method non-static, but then I would require an instance of it which I wouldn't always have. Also I can't call a static method from the generic type E either. I suppose I could make two interfaces, one for groups and one for elements of groups, but then it seems like it would really complicate code from something like the InverseChecker object (would need two type parameters for everything and I would have to re-write a lot of my code, and I'm not sure how I would specify the relationship between the two interfaces). Also I just realized when typing this out that the way the interface is constructed you would have to allow group operations between two elements from different groups, which doesn't make sense. So, what is the correct way to implement this kind of structure?

Answer 1

The solution here -- such as it is -- is to look at things in a different direction. The group should be a separate object from its elements, and the group object should have a T operate(T, T) and a T identity() method.

In other words, stop trying to have a GroupElement interface and have a Group interface.

Also, generics would probably simplify matters: a Group<T> with elements of type T .

Answer 2

Consider the clause in the first sentence: "instances of a certain class represent elements of a set". That contains two problem-related nouns, "element" and "set". My initial thinking, subject to change as I learn more about the problem, would be to have two classes, Element and Set. I might rename "Set" to avoid confusion with java.util.Set - if this is Group Theory, "Group" would be a good alternative.

If you do that, you can put element related methods in Element, and set-related methods in Set. Both can be subclassed, with normal overriding.