タグ付けされた質問 「factory」

GitHubとCodePlexでいくつかのС＃とJavaクラスライブラリプロジェクトの歴史を見てきました。オブジェクトの直接インスタンス化とは対照的に、ファクトリクラスに切り替える傾向が見られます。 なぜファクトリクラスを広範囲に使用する必要があるのですか？クラスのパブリックコンストラクターを呼び出すことで、昔ながらの方法でオブジェクトが作成される、非常に優れたライブラリがあります。最後のコミットで、著者は数千のクラスのすべてのパブリックコンストラクターCreateXXXをすぐに内部に変更し、クラスの内部コンストラクターを呼び出して新しいオブジェクトを返すだけの数千の静的メソッドを持つ1つの巨大なファクトリークラスを作成しました。外部プロジェクトAPIは壊れており、よくできています。 なぜこのような変更が役立つのでしょうか？このようにリファクタリングのポイントは何ですか？パブリッククラスコンストラクターの呼び出しを静的ファクトリメソッド呼び出しに置き換えることの利点は何ですか？ いつパブリックコンストラクターを使用する必要があり、いつファクトリーを使用する必要がありますか？

162 design-patterns  refactoring  constructors  factory 

このShapeFactoryが条件付きステートメントを使用して、インスタンス化するオブジェクトを決定するのはなぜですか。将来他のクラスを追加する場合、ShapeFactoryを変更する必要はありませんか？なぜこれはオープンクローズド原則に違反しないのですか？

13 design  design-patterns  factory-method  factory 

ソフトウェアの構成にDIC / IoCレジストリを使用するタイミングと、ファクトリを使用するタイミング、およびどちらのアプローチの背後にある理由も理解しようとしています。 レジストリを使用して簡単に構成できるDIコンテナー（DIC）としてStructureMapを使用しています。DICでは、実質的にすべての登録済みオブジェクトは静的です。つまり、DICが構成され、DICでシングルトンとして構成されたら、実行時に実装/インスタンスを変更/交換する必要はありません。ただし、ソフトウェア（SW）はさまざまなデバイスで実行されるため、ハードウェアを適切に構成するには、ソフトウェアが実行されるデバイスに応じてデバイス固有のレジストリを選択する必要があります。 一部のオブジェクトの構築には構成ファイルの読み取りが必要なため、構成の読み取りとオブジェクトの作成を分離するために、ファクトリを使用してこれらのインスタンスをDICに返しています。対応するプラグインタイプのファクトリゲッターをDICに登録しました。 IMotor具象型Motor1とを備えたプラグイン型があるとしましょうMotor2。これはファクトリで処理する必要があります。デバイスの構成方法を決定する方法は2つあります。 私はSWが上に実行されていることをデバイスに関する情報を渡しMotorFactory、それが正しいモータを返す、のいずれかMotor1、またはMotor2。この場合、決定のロジックはファクトリー内にあります。 DICを実行しているデバイスに応じてDICを構成し、2つのファクトリMotor1Factoryを作成します。1 Motor2Factoryつは作成Motor1し、もう 1つは作成しますMotor2。この場合IMotor、Motor1Factoryまたはのいずれかを使用するデバイス固有のレジストリに、異なるレジストリエントリが含まれますMotor2Factory。 今私の質問です：これらの2つの方法のどちらが望ましいのですか？私には、コードベース全体でどのタイプをインスタンス化するかを決定するロジックを広げているため、最初のケースは単純ではなく複雑です。一方、2番目のケースでは、コード内のファクトリの数を効果的に増やしています。これは、（ほとんど）各具象型のファクトリが必要になるためです。抽象ファクトリーがミックスに追加されると、さらに混乱します。 繰り返しますが、どちらの方法を使用すればよいですか？さらに重要なのは、どちらの方法に進むかを決定するための優れた指標は何ですか？

9 configuration  factory  ioc-containers