非常に特殊なタスクを実行するオブジェクトがあります。このオブジェクトを作成するには、いくつかのパラメータが必要です。システムの一部に新しいインスタンスを作成します。しかし、問題があります。将来、パラメーターまたは引数を変更する必要がある場合はどうなりますか? どこでも変更する必要があります。それから私は考えました:「まあ、その作成をクラスにカプセル化できるかもしれません。引数が変更された場合、1 か所だけ変更する必要があります!」.
それは私にとって完全に理にかなっています。問題は、この「ラッパー」オブジェクトがファクトリかどうかです。その責任は、「特定のパラメーターを使用して新しいオブジェクトを作成し、それを返す」ことです。消費者はこのオブジェクトを使用するだけです...
重複を避けるためにコードをリファクタリングすることで、全体的な保守性が向上する可能性があります。
このリファクタリングされたコードがオブジェクトを作成している場合、はい、それはファクトリです。あなたがそれを何と呼ぶかは本当に問題ではありません - あなたのコードはより良く構造化されていますか? じゃやれ！
ただし、これが工場であることを考えると、工場に関する古典的な設計パターンを研究し、人々がこのパターンのより洗練された形式を使用するように導く理由を理解してください。彼らに「賢い」工場を使わせる力があるかどうかを判断してください。
あなたが説明する問題は、そのクラスのコンストラクターパラメーターが変更されたときに、クラスのすべてのクライアントを変更する必要があることです。ファクトリを導入すると、クライアントの再コンパイルを防ぐことができます。しかし、これで本当に問題は解決するのでしょうか? クラスを別のパラメーターで構築するように変更する場合、おそらく構築を開始するクライアントのコンテキストで、そのパラメーターをどこかで決定する必要があります。ファクトリクラスはどのように知る必要がありますか? クライアントはコンテキスト情報をファクトリに渡す必要がありますか?
オブジェクトを構築するために必要なパラメーターは何ですか? クライアントはそれらを提供しますか、それともオブジェクトを事前に作成してから、ファクトリを注入するようにクライアントに注入できますか (あなたの質問は後者のようです)。DI フレームワークの使用を検討してください。これにより、工場が時代遅れになることがよくあります。
クラスが変更される可能性が高いのはなぜですか？あなたのクラスはあまりにも多くのことをしている可能性がありますか? 単一責任の原則に注意してください。あなたの場合、Open/Closed Principleも興味深い研究です。
私が理解しているように、工場は必ずしもあなたが説明した問題に対処するとは限りません。ファクトリはクライアントから離れてオブジェクトを作成する責任を負うため、クライアントはオブジェクトの具体的なタイプを知る必要はありません。署名が安定したままになるのを防ぐだけでも、パラメーターを単一のオブジェクトにラップすることで実行できます。これもよく知られたリファクタリング パターンです。しかし、新しいパラメーターがどこから来たのかという問題も解決しません。