Как реализовать абстрактные статические методы в Java?

математическая группа имеет только одну характеристическую операцию, однако класс Java может иметь любое количество операций. Поэтому эти два понятия не совпадают.

Я могу представить себе что-то вроде Java class Group состоящий из Set элементов и конкретной операции, которая будет интерфейсом сама по себе. Что-то вроде

public interface Operation<E> {
   public E apply(E left, E right);
}

С этим, вы можете создать свою группу:

public abstract class Group<E, O extends Operation<E>> {
    public abstract E getIdentityElement();
}

Я знаю, что это не совсем то, что вы имели в виду, но как я уже говорил выше, математическая группа-это несколько иное понятие, чем класс.

там могут быть некоторые misunderstaning в ваших рассуждениях. Вы видите, что математическая "группа" такова, как вы ее определяете (если я хорошо помню); но ее элементы не характеризуются тем, что они принадлежат к этой группе. Я имею в виду, что целое число (или реальное) является автономной сущностью, которая также принадлежит группе XXX (среди других ее свойств).

Итак, в контексте программирования я бы разделил определение (class) формы группы, которая ее членов, вероятно, используя дженерики:

interface Group<T> {
    T getIdentity();
    T compose(T, T);
}

еще более аналитическое определение будет:

/** T1: left operand type, T2: right ..., R: result type */
interface BinaryOperator<T1, T2, R> {
    R operate(T1 a, T2 b);
}

/** BinaryOperator<T,T,T> is a function TxT -> T */
interface Group<T, BinaryOperator<T,T,T>> {
    void setOperator(BinaryOperator<T,T,T> op);
    BinaryOperator<T,T,T> getOperator();
    T getIdentity();
    T compose(T, T); // uses the operator
}

все это идея; я на самом деле не прикасался к математике в течение длительного времени, поэтому я могу быть дико неправ.

удачи!

нет способа java сделать это (вы можете сделать что-то подобное в Scala), и все обходные пути, которые вы найдете, основаны на некотором соглашении о кодировании.

типичный способ, которым это делается на Java, - это иметь свой интерфейс GroupElement объявите два статических метода, таких как это:

public static <T extends GroupElement> 
  T identity(Class<T> type){ /* implementation omitted */ }

static <T extends GroupElement> 
  void registerIdentity(Class<T> type, T identity){ /* implementation omitted */ }

вы можете легко реализовать эти методы с помощью класс для экземпляра map или домашние решением. Дело в том, что ты держишь статическая карта элементов идентичности, по одному на каждый GroupElement реализация.

и здесь возникает необходимость в Конвенции: каждый подкласс GroupElement придется статически объявить свой собственный элемент личности, например,

public class SomeGroupElement implements GroupElement{
  static{
    GroupElement.registerIdentity(SomeGroupElement.class, 
      /* create the identity here */);
  }
}

на identity метод вы можете бросить RuntimeException если личность никогда не была зарегистрирована. Это не даст вам статическую проверку, но, по крайней мере, проверку времени выполнения для вашего GroupElement классы.

альтернатива этому немного более многословна и требует, чтобы вы создали экземпляр вашего GroupElement классы только через фабрику, которая также позаботится о возвращении элемента идентификатора (и других подобных объектов / функций):

public interface GroupElementFactory<T extends GroupElement>{
  T instance();
  T identity();
}

это шаблон, обычно используемый в корпоративных приложениях, когда фабрика вводится через некоторые рамки инъекций зависимостей (Guice, Spring) в приложении, и это может быть слишком многословным, сложнее поддерживать и, возможно, перебор для вас.

редактировать: после читая некоторые другие ответы, я согласен, что вы должны моделировать на уровне группы, а не на уровне элемента группы, поскольку типы элементов могут быть разделены между различными группами. Тем не менее, приведенные выше ответы предоставляют общий шаблон для обеспечения описываемого вами поведения.

правка 2: под" соглашением о кодировании " выше я имею в виду статический метод getIdentity в каждом подклассе GroupElement, как говорили некоторые. Этот подход имеет обратную сторону, не позволяя generic алгоритмы, которые будут написаны против группы. Еще раз, лучшим решением для этого является тот, который упоминается в первом редактировании.

Если вам нужна возможность генерировать идентификатор, где класс не известен во время компиляции, первый вопрос: как вы знаете, во время выполнения, какой класс вы хотите? Если класс основан на каком-то другом объекте, то я думаю, что самый чистый способ-определить метод в суперклассе, который означает "получить идентификатор, класс которого такой же, как" какой-то другой объект.

public GroupElement getIdentitySameClass();

это должно быть переопределено в каждом подклассе. Переопределение, вероятно, не будет использовать объект; объект будет использоваться только для выбора правильного getIdentity называть полиморфно. Скорее всего, вам также понадобится static getIdentity в каждом классе (но я не знаю, как компилятор может заставить его писать), поэтому код в подклассе, вероятно, будет выглядеть как

public static GInteger getIdentity() { ... whatever }

@Override
public GInteger getIdentitySameClass() { return getIdentity(); }

С другой стороны, если класс вам необходимо из Class<T> объект, я думаю, вам нужно будет использовать отражение, начиная с getMethod. Или увидеть ответ Джованни, который, я думаю, лучше.

мы все согласны, если вы хотите реализовать группы, вам понадобится групповой интерфейс и классы.

public interface Group<MyGroupElement extends GroupElement>{
    public MyGroupElement getIdentity()
}

мы реализуем группы как синглтоны таким образом, мы можем получить доступ getIdentity статически через instance.

public class GIntegerGroup implements Group<GInteger>{

    // singleton stuff
    public final static instance = new GIntgerGroup();
    private GIntgerGroup(){};

    public GInteger getIdentity(){
        return new GInteger(0);
    }
}

public class PosRealGroup implements Group<PosReal>{

    // singleton stuff
    public final static instance = new PosRealGroup();
    private PosRealGroup(){}        

    public PosReal getIdentity(){
        return new PosReal(1);
    }
}

если нам также нужно иметь возможность получить идентификатор из элемента группы, я бы обновил ваш GroupElement интерфейс:

public Group<GroupElement> getGroup();

и GInteger с:

public GIntegerGroup getGroup(){
    return GIntegerGroup.getInstance(); 
}

и PosReal с:

public PosRealGroup getGroup(){
    return PosRealGroup.getInstance(); 
}

" в getIdentity способ не dependonany экземпляр объекта, и, следовательно, должен быть объявлен static"

на самом деле, если он не зависит от какого-либо экземпляра, он может просто вернуть некоторое постоянное значение, оно не должно быть статическим.

только потому, что статический метод не зависит от экземпляра, это не означает, что вы должны использовать его всегда для такого рода ситуации.