假设有两个类，父类和子类。父母是抽象的。声明如下:

abstract class Parent {
    abstract void run();
}

class Child extends Parent {
    void run() {}
}

这意味着Parent的任何实例都必须指定如何执行run()。

但是，现在假设Parent不是抽象的。

class Parent {
    static void run() {}
}

这意味着Parent.run()将执行静态方法。

抽象方法的定义是“声明但未实现的方法”，这意味着它本身不返回任何东西。

静态方法的定义是“对于相同的参数返回相同值的方法，而不管调用它的实例是什么”。

抽象方法的返回值会随着实例的改变而改变。静态方法则不会。静态抽象方法基本上是这样一种方法，它的返回值是常量，但不返回任何东西。这是一个逻辑矛盾。

同样，使用静态抽象方法的理由也不多。

因为“抽象”意味着方法是要被重写的，而不能重写“静态”方法。

使用抽象静态方法的想法是，您不能直接为该方法使用特定的抽象类，但只允许一阶导数实现该静态方法(或者对于泛型:您使用的泛型的实际类)。

通过这种方式，您可以创建sortableObject抽象类甚至接口 使用(auto-)抽象静态方法，定义排序选项的参数:

public interface SortableObject {
    public [abstract] static String [] getSortableTypes();
    public String getSortableValueByType(String type);
}

现在你可以定义一个可排序对象，它可以根据所有这些对象的主要类型进行排序:

public class MyDataObject implements SortableObject {
    final static String [] SORT_TYPES = {
        "Name","Date of Birth"
    }
    static long newDataIndex = 0L ;

    String fullName ;
    String sortableDate ;
    long dataIndex = -1L ;
    public MyDataObject(String name, int year, int month, int day) {
        if(name == null || name.length() == 0) throw new IllegalArgumentException("Null/empty name not allowed.");
        if(!validateDate(year,month,day)) throw new IllegalArgumentException("Date parameters do not compose a legal date.");
        this.fullName = name ;
        this.sortableDate = MyUtils.createSortableDate(year,month,day);
        this.dataIndex = MyDataObject.newDataIndex++ ;
    }
    public String toString() {
        return ""+this.dataIndex+". "this.fullName+" ("+this.sortableDate+")";
    }

    // override SortableObject 
    public static String [] getSortableTypes() { return SORT_TYPES ; }
    public String getSortableValueByType(String type) {
        int index = MyUtils.getStringArrayIndex(SORT_TYPES, type);
        switch(index) {
             case 0: return this.name ;
             case 1: return this.sortableDate ;
        }
        return toString(); // in the order they were created when compared
    }
}

现在您可以创建一个

public class SortableList<T extends SortableObject> 

它可以检索类型，构建一个弹出菜单来选择要排序的类型，并通过从该类型获取数据来返回列表，以及hainv一个add函数，当选择了排序类型时，可以自动对新项进行排序。 注意SortableList实例可以直接访问“T”的静态方法:

String [] MenuItems = T.getSortableTypes();

必须使用实例的问题是SortableList可能还没有项目，但已经需要提供首选排序。

再见 奥拉夫。

在一行中，这种危险的组合(抽象+静态)违反了面向对象的原则，即多态性。

在继承情况下，JVM将在运行时根据实现决定实例的类型(运行时多态性)，而不是根据引用变量的类型(编译时多态性)。

@Overriding:

静态方法不支持@ override(运行时多态性)，而只支持方法隐藏(编译时多态性)。

@Hiding:

但是在抽象静态方法的情况下，父(抽象)类没有方法的实现。因此，子类型引用是唯一可用的，而且它不是多态性。

子引用是唯一可用的:

出于这个原因(抑制oop特性)，Java语言认为抽象+静态是非法(危险)的方法组合。

这是一个糟糕的语言设计，真的没有理由不可能。

事实上，这里有一个模式或方法可以在**Java中模仿它，让你至少能够修改自己的实现:

public static abstract class Request {                 

        // Static method
        public static void doSomething() {
                get().doSomethingImpl();
        }
        
        // Abstract method
        abstract void doSomethingImpl();

        /////////////////////////////////////////////
        private static Request SINGLETON;
        private static Request get() {
            if ( SINGLETON == null ) {
                // If set(request) is never called prior,
                // it will use a default implementation. 
                return SINGLETON = new RequestImplementationDefault();
            }
            return SINGLETON;
        }
        public static Request set(Request instance){
            return SINGLETON = instance;
        }
        /////////////////////////////////////////////
}

两种实现:

/////////////////////////////////////////////////////

public static final class RequestImplementationDefault extends Request {
        @Override void doSomethingImpl() {
                System.out.println("I am doing something AAA");
        }
}

/////////////////////////////////////////////////////

public static final class RequestImplementaionTest extends Request {
        @Override void doSomethingImpl() {
                System.out.println("I am doing something BBB");
        }
}

/////////////////////////////////////////////////////

可以这样使用:

Request.set(new RequestImplementationDefault());

// Or

Request.set(new RequestImplementationTest());

// Later in the application you might use

Request.doSomething();

这将允许您静态地调用方法，同时还能够更改例如Test环境的实现。

理论上，您也可以在ThreadLocal上执行此操作，并且能够为每个线程上下文设置实例，而不是像这里所示的完全全局，然后可以执行Request。withRequest(anotherRequestImpl，() ->{…})或类似的。

现实世界通常不需要ThreadLocal方法，通常能够全局地改变测试环境的实现就足够了。

请注意，这样做的唯一目的是能够保留静态方法所提供的直接、轻松和干净地调用方法的能力，同时能够切换实现，以牺牲稍微复杂的实现为代价。

它只是一种绕过通常不可修改的静态代码的模式。

糟糕的语言设计。直接调用静态抽象方法要比为使用该抽象方法而创建实例有效得多。当使用抽象类作为枚举无法扩展的变通方法时尤其如此，这是另一个糟糕的设计示例。希望他们能在下一个版本中解决这些限制。