在接口中創建具體實現的新實例 - 這是反模式嗎？

Question

假設我的接口AuthorDao具有兩個不同的實現類，例如MyAuthorDaoImpl1和MyAuthorDaoImpl2 。

在我的界面AuthorDao ，我有一些基本的 crud 方法和一個額外的方法，即static用於獲取MyAuthorDaoImpl1的新實例。

它看起來像這樣：

public interface AuthorDao {

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

問題

1. 這個 static 方法getInstance()不是反模式嗎？ 因為在我看來，我們的接口不應該依賴於具體的實現 class，但是我的朋友說沒關系，他很確定，這應該是這樣的。 他說這是工廠方法。
2. 他說我們可以通過構造函數創建這個接口的實例，我們不必使用這個static方法，因此這沒什么不好。 真的嗎，這沒什么不好？ 我認為這是緊耦合的例子，接口不應該依賴於具體的實現，但他說事實並非如此。
3. 他提到這與Calendar class 中的情況相同，因為還有getInstance()方法。

---

編輯

此外，在他看來，如果我們決定將MyAuthorDaoImpl1 MyAuthorDaoImpl2則此 static 方法將簡化重構。 因為唯一的變化將在getInstance()方法中。

Answer 1

這個實現是一個循環依賴，大致如下：

雖然它可能會在 Java 中工作，但想象一下，如果您稍后決定實施ABetterAuthorDaoImpl時不再包含 class MyAuthorDaoImpl會發生什么。 現在您必須更改界面。 在這種情況下，這是一個微小的變化，但可以在更大的范圍內想象它。

通常，工廠方法返回接口類型而不是實現類型。 例子：

class AuthorDaoFactory {

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

這避免了循環依賴，如下圖所示：

您會注意到依賴項中沒有循環路徑。 對於這個簡單的示例，這可能無關緊要，但是如果您的工廠方法創建了一個基於配置動態加載的 class 實例怎么辦？ 這是控制反轉 (IoC) 的一個常見示例，通常用於執行諸如為不同硬件提供通用接口之類的操作。 實現隱藏在接口后面。

您會注意到 Java Calendar class 方法getInstance返回類型Calendar 。 底層實現可能是特定於語言環境的。 如果您查看 Java 文檔中的方法描述，它會說：

獲取使用默認時區和語言環境的日歷。 返回的日歷基於具有默認語言環境的默認時區中的當前時間。

那么具體的實現方式是什么？ 你不知道也不在乎，你只知道它是Calendar類型。