java - 在接口(interface)中创建具体实现的新实例 - 这是反模式吗？

Question

假设我有接口(interface) AuthorDao具有两个不同的实现类，例如 MyAuthorDaoImpl1和 MyAuthorDaoImpl2 .
在我的界面AuthorDao我有一些基本的 crud 方法和 一种额外的方法是static 获取 MyAuthorDaoImpl1 的新实例.
它看起来像这样:

public interface AuthorDao {

    void methodA();
    void methodB();
    ...
   
    static MyAuthorDaoImpl getInstance() {
        return new MyAuthorDaoImpl1();
    }
}

问题

这是静态方法吗getInstance()是不是反模式？
因为在我看来，我们不应该将我们的界面依赖于具体的
实现类，但我的 friend 说没关系，他很确定，这应该是这样的。他说是工厂方法 .

他说我们可以通过构造函数创建这个接口(interface)的实例，我们不必使用这个static方法，因此这没什么不好。真的吗，这没什么不好？我认为这是 的示例紧耦合和接口(interface)不应该依赖于具体的实现，但他说情况并非如此。

他提到这与 Calendar 中的情况相同。类，因为还有getInstance()方法。

编辑
此外，在他看来，如果我们决定更改 MyAuthorDaoImpl1，这种静态方法将简化重构。至 MyAuthorDaoImpl2 .
因为唯一的变化将在 getInstance()方法。

Answer 1

这个实现是 circular dependency ，大致如下:

虽然它很可能在 Java 中工作，但想象一下如果你不再包含类 MyAuthorDaoImpl 会发生什么后来你决定实现ABetterAuthorDaoImpl .现在您必须更改界面。在这种情况下，这是一个微小的变化，但可以在更大的范围内想象它。
通常，工厂方法返回接口(interface)类型而不是实现类型。例子:

class AuthorDaoFactory {

    static AuthorDao getInstance() {
        return new MyAuthorDaoImpl1();
    }
}

这避免了循环依赖，如下图所示:

您会注意到依赖项中没有循环路径。对于这个简单的示例，这可能无关紧要，但是如果您的工厂方法创建了一个基于配置动态加载的类的实例呢？这是 Inversion of Control (IoC) 的常见示例并且经常被用来做一些事情，比如为不同的硬件提供一个通用的接口(interface)。实现隐藏在接口(interface)后面。
您会注意到 Java Calendar类方法 getInstance返回类型 Calendar .底层实现可能是特定于语言环境的。如果您查看 Java 文档中对该方法的描述，它会说:

Gets a calendar using the default time zone and locale. The Calendar returned is based on the current time in the default time zone with the default locale.

那么具体的实现方式是什么？你不知道也不在乎，你只知道它是 Calendar 类型.