オブジェクト作成のための「静的ファクトリメソッド対コンストラクタ」が議論されている有効なJavaアイテム1を調べていました。上記の欠点の1つは次のとおりです。Effective Java Item1 - オブジェクト作成のための静的ファクトリメソッド
"静的ファクトリメソッドのみを提供することの主な欠点は、パブリックまたは保護されたコンストラクタのないクラスはサブクラス化できないことです。
オブジェクトの合成を継承に促進するので、これは良いことだとも言われています。しかし、本当に相続が必要な場合、それは深刻な制限ではありませんか？なぜクラスが拡張されるかどうかわからないときに、オブジェクト作成のための静的ファクトリメソッドを好むべきですか？
クラスが拡張されるかどうかわからないときに、オブジェクト作成用の静的ファクトリメソッドを好むのはなぜですか？
この質問への答えは、効果的なJavaの項目17である：デザインとドキュメント継承のためか、そうでなければを禁止します。継承のためのクラスを設計するには、次のような作業が必要です。
CloneableおよびSerializableのインターフェイスとその継承への影響を検討してください。この作業をすべて完了していれば、は、スタティックファクトリメソッドのみを提供しません。少なくとも1つのパブリックまたは保護されたコンストラクタも提供します。
効果的なJavaは、これらの点のそれぞれについて詳しく説明しますが、最終的なアドバイスがあり、この問題へ
最善の解決策は、安全にサブクラス化するように設計され、文書化されていないクラスでサブクラス化を禁止することです。
引用は次のとおりです。
提供のみstaticファクトリメソッドの主な欠点はpublicまたはprotectedコンストラクタのないクラスをサブクラス化することができないということです。
ないstaticファクトリのが、提供のみstaticファクトリメソッドの、違いを感じます。
拡張のために設計する必要があります。「まあ、今はあまりよく分からないかもしれませんが、場合によっては拡張性を持たせておきます。
クラスが拡張可能な場合は、少なくともpublicコンストラクタが必要です。この場合、はの静的ファクトリメソッドのみを指定できます。しかし、私はそれを深刻な制限と呼んでいません。
質問の間違いを指摘してくれてありがとう。私は今それを修正しました。 –
しかし、私は違いの工場と静的なファクトリメソッドを理解しています。私はファクトリではなく静的ファクトリメソッドを意味していました。 –
私が書いたように、拡張性のための静的なファクトリメソッドだけでなく、*を提供する必要があります。そのような大きな制限ではありません。 – lexicore
返信いただきありがとうございました、本の項目17を指摘してください！ –