オブジェクト作成のための「静的ファクトリメソッドとコンストラクター」が議論されている効果的なJava項目1を調べていました。言及されている欠点の1つは次のとおりです。
「静的ファクトリ メソッドのみを提供することの主な欠点は、パブリックまたは保護されたコンストラクターを持たないクラスをサブクラス化できないことです。」
オブジェクト合成を継承に促進するので、これは良いとも言われています。しかし、どうしても継承が必要な場合、それは深刻な制限ではありませんか? クラスが拡張されるかどうか以前からわからないのに、オブジェクトの作成に静的ファクトリ メソッドを使用する必要があるのはなぜですか?
クラスが拡張されるかどうか以前からわからないのに、オブジェクトの作成に静的ファクトリ メソッドを優先する必要があるのはなぜですか?
この質問に対する答えは、Effective Java Item 17: Design and Document for Inheritance or else Prohibit It にあります。継承用のクラスを設計するには、次のようなかなり多くの作業が必要です。
CloneableインターフェイスとSerializableインターフェイス、および継承への影響を考慮します。この作業をすべて行った場合、静的ファクトリ メソッドだけを提供することはありません。また、パブリックまたは保護されたコンストラクターを少なくとも 1 つ提供します。
効果的な Java は、これらの各ポイントについて詳しく説明しますが、最終的なアドバイスは次のとおりです。
この問題の最善の解決策は、安全にサブクラス化できるように設計および文書化されていないクラスでのサブクラス化を禁止することです。
引用は次のとおりです。
静的ファクトリ メソッドのみを提供することの主な欠点は、パブリック コンストラクターまたはプロテクト コンストラクターを持たないクラスをサブクラス化できないことです。
静的ファクトリではなく、静的ファクトリ メソッドのみを提供することの違いを感じます。
「まあ、今はよくわからないかもしれませんが、念のため拡張可能のままにします」ではなく、拡張用に設計する必要があります。
クラスが拡張可能な場合、少なくとも public コンストラクターが必要です。この場合、静的ファクトリ メソッドのみを提供できます。しかし、私はそれを深刻な制限とは呼びません。