以下（反）模式的名称是什么？它的优缺点是什么？

在过去的几个月中，我偶然发现了以下技术/模式。但是，我似乎找不到一个特定的名称，也不能百分百确定其所有优点和缺点。

模式如下：

在Java接口中，照常定义了一组常用方法。但是，使用内部类，默认实例会通过接口泄漏。

public interface Vehicle {
    public void accelerate();
    public void decelerate();

    public static class Default {
         public static Vehicle getInstance() {
             return new Car(); // or use Spring to retrieve an instance
         }
    }
 }

对我来说，最大的优势似乎在于，开发人员只需要了解接口，而无需了解其实现，例如，在他快速想要创建实例的情况下。

 Vehicle someVehicle = Vehicle.Default.getInstance();
 someVehicle.accelerate();

此外，我已经看到该技术与Spring一起使用，以便根据配置动态提供实例。在这方面，它看起来也可以帮助模块化。

但是，我无法撼动这是滥用接口的感觉，因为它将接口与其实现之一结合在一起。（相关性反转原理等。）有人可以向我解释该技术的调用方式以及它的优缺点吗？

更新：

经过一段时间的考虑后，我重新检查并注意到，使用以下单例版本的模式的频率更高。在此版本中，公共静态实例通过接口公开，该接口仅初始化一次（由于字段为final）。另外，几乎总是使用Spring或将接口与实现分离的通用工厂来检索实例。

public interface Vehicle {
      public void accelerate();
      public void decelerate();

      public static class Default {
           public static final Vehicle INSTANCE = getInstance();

           private static Vehicle getInstance() {
                return new Car(); // or use Spring/factory here
           }
      }
 }

 // Which allows to retrieve a singleton instance using...
 Vehicle someVehicle = Vehicle.Default.INSTANCE;

简而言之：这似乎是一个自定义的单例/工厂模式，它基本上允许通过其接口公开实例或单例。关于缺点，下面的答案和评论中提到了一些缺点。到目前为止，优势似乎在于其便利性。

Default.getInstance恕我直言，IMHO只是工厂方法的一种非常特殊的形式，与取自单例模式的命名约定混合在一起（但不是后者的实现）。在当前形式中，这违反了“ 单一职责原则 ”，因为接口（已经用于声明类API的目的）承担了提供默认实例的额外职责，最好将其放置在单独的实例中VehicleFactory类。

这种结构引起的主要问题是，它引起Vehicle和之间的循环依赖Car。例如，在当前形式下，将无法放置Vehicle在一个库中，而Car在另一个库中。使用单独的工厂类并在其中放置Default.getInstance方法将解决该问题。给该方法起一个不同的名字也可能是一个好主意，以防止与单例相关的任何混乱。所以结果可能像

VehicleFactory.createDefaultInstance()

在我看来，这就像Null Object模式。

但这在很大程度上取决于Car类的实现方式。如果以“中立”的方式实现，那么它肯定是一个Null对象。这意味着，如果您可以删除接口上的所有null检查，并放置此类的实例而不是每次出现的null，则代码仍必须能够正常工作。

同样，如果是这种模式，那么在接口本身与null对象的实现之间创建紧密的耦合也没有问题。因为空对象可以在使用所述接口的任何地方。