問題タブ [abstract-factory]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - デザイン パターン: 抽象ファクトリと汎用リポジトリ
これが私のドメインモデルと汎用リポジトリの設計です
リポジトリ インスタンスをインスタンス化する場合は、次のインターフェイスを実装するファクトリを使用します
そして、以下のようにファクトリオブジェクトを使用します
私の問題は2行目にあります。私は自分の工場を次のように使用したいと思います。
私の IRepository インターフェイスにはエンティティのタイプに関する制約があるため、私のファクトリは同じ制約を使用して IRepository の要件を満たします。
このパラメータをクライアントから分離する方法はありますか?
.net - MEF のインスタンス化とマルチスレッド化
.Net 4.0 で MEF を使用して、かなりの量の抽象ファクトリ コードと構成ガビンを節約しています。展開されていないため、.net 4.5 に移行できません。
クラス
が呼び出された後_container.ComposeParts(this);
、見つかったすべての IMessageProcessor 実装が Processors に取り込まれます。偉大な。
ノート
- GetMessageProcessor は多くのスレッドによって呼び出されます。
- 開発者が IMessageProcessor のクラス実装をどのように構築するかを制御することはできません。したがって、それらがスレッド セーフ (再入可能) であることを保証することはできません。ただし、クラスは Export 属性でインストルメント化する必要があります。
エクスポート属性
- ExpectedType は、IMessageProcessor.ProcessMessage() が処理することを期待するもの、純粋に実装の詳細を示す単なるメタデータです。
私の問題は、Lazy<> 参照を介して構築されたときのアクティブ化ポリシーに関係なく、インポートされた各インスタンスがシングルトンになることをどこでも読んでいることです。
したがって、複数のスレッドが同じインスタンスを取得しようとしており、これは望ましくないため、MEF からのインスタンスを GetMessageProcessor から返すことはできません。ああ!次の「回避策」が最善のアプローチなのか、それとも MEF の主張の概念が間違っているのか疑問に思っていました。
私の回避策は、一見無意味に見えるRequiredCreationPolicy = CreationPolicy.NonShared
属性設定をに変更することCreationPolicy.Shared
です。
次に、関数 GetMessageProcessor を変更して、新しいインスタンスを手動で作成し、MEF から完全に分離します。タイプのリストとして MEF 共有インスタンス prulry を使用します。
完全な方法。
abstract-factory - 抽象ファクトリの悪いデザイン?
さまざまなサイズの車を製造する自動車工場があります。私には2つの工場があります。アメリカとタイで、車のサイズをビッグ、ミドル、リトルにしています。しかし、私には問題があります。タイの工場は大きな車を製造していません。
コード:
私は何をすべきか?私のAbstractFactoryは不十分に設計されていますか?
unity-container - Unity の自動抽象ファクトリー
私は Unity を初めて使用し、Unity の Auto Factory の概念を拡張する方法を理解するのに苦労しています。Unity は、パラメータ自体の代わりに Func を使用してファクトリを作成する機能を提供します。そのように:
問題は、ファクトリによって作成されたクラスがいくつかのパラメーターを必要とする場所があり、それらのパラメーターは実行時にしかわかりません。それ以外では、これらのパラメーターの数と型はクラスによって異なります。
私が探しているのはAutofac DelegateFacotryに似たものですが、Unityの感覚を保ちたいと思います。したがって、Unity を次のように動作させたいと考えています。
Unityはそのコンストラクターで動作するため、上記のコードは機能しませんが、まさに私が探しているものです.
BuilderStrategy を使用してみましたが、それは式または IL 生成のいずれかに要約されます。その道を進む前に、他のオプションを確認したいと思います。
それを手伝ってくれる Unity の経験が豊富な人はいますか?
私が持っている制約は次のとおりです。
- Func を使用するという Unity の概念を維持する
- コンテナー内のすべての Func を登録する必要はありません
- コンストラクターは、Func から Func への Func を受け入れる必要があります (Func は既に処理されています)。
- コンテナの変更はオプションではありません
私が十分に明確だったことを願っています。そうでない場合は、お知らせください。
編集 1 : 抽象ファクトリを直接使用できることを理解しています。でも、第一の目標はUnityのフィーリングを保つことです。
c++ - ファースト クラス オブジェクトとしての抽象ファクトリとクラス
理論的な質問です。私はGofのデザインパターン、セクションAbstract Factoryを読んでいます。この本では、このパターンをプロトタイプのように実装する可能性、または言語が許可する場合は、オブジェクトの代わりにクラスを格納するプロトタイプを使用する可能性について言及しています。
私はこれを理解しました。たとえば、Java や Smalltalk では、クラスもオブジェクトです (Java では、クラスは実際にはクラス Class のインスタンスです)。したがって、それらをクラス内に格納し、必要に応じてこれらのクラスのインスタンスの作成を呼び出すことができます。
C++ では、クラスはファースト クラス オブジェクトではありません。したがって、このアプローチに従うことはできません。しかし、Concrete Factory 内でネストされたクラスを、そのコンストラクターを呼び出す (そしてそのインスタンスを返す) メソッドで宣言できないでしょうか? 最終的な結果は、Java や Smalltalk などの他の言語と同じになります。私は正しいですか?
ご清聴ありがとうございました。
java - ジェネリック型キャスト?
抽象ファクトリ パターンでは、ジェネリックを使用しています。Serializable を拡張する BaseEntity インターフェイスがあり、Employee クラスは BaseEntity を実装します。抽象クラスには、この getJavaObj メソッドがあります
getJavaObj()
Long empId
を受け取って返すメソッドです。Map<String, ? extends BaseEntity>
ジェネリックを使用して、それが提供するメインクラスでこれを実行しようとしています。
このエラーが発生します Type safety: Unchecked cast from Map<String,capture#1-of ? extends BaseEntity>
to Map
このように型キャストを行うと
この警告が表示されます
型の安全性: から Map への未チェックのキャスト型の安全性: からMap へ
Map<String,capture#1-of ? extends Serializable>
の未チェックのキャストMap<String,capture#1-of ? extends BaseEntity>
型キャストを回避したり、型キャスト後でも警告を解決する方法はありますか? 私が返しているオブジェクトは、BaseEntity インターフェイスを介して Serializable に拡張されているためです。
java - Java ThreadFactory によって作成されたオブジェクトへのすべての参照を null にするアプローチ
Android アプリケーションで実行可能なスレッド サブクラス オブジェクトを生成する Java ThreadFactory 実装があります。このアプリケーションでは、特定のイベントが発生する前に生成されたすべてのスレッドがアドレス指定可能であり、そのイベントの起動時に、生成されたスレッドがガベージ コレクションの対象になる (参照カウント 0 など) 必要があります。最初の要件を満たすには、スレッド オブジェクトの ArrayList を維持するだけで、うまく機能すると考えていました。問題は 2 番目の要件に伴い、Java 参照カウントに関する一連の質問につながりました。
質問 1: 生成されたスレッドへの参照を ArrayList または他のコンテナーに格納するだけで、各スレッド オブジェクトの参照カウントが増加しますか? 各スレッド オブジェクトの参照カウントは、それらを保存せずに、ファクトリがそれらを作成し、以下のように定義されたハンドルなしで実行できるようにした場合はどうなりますか?
質問 2: 以下のコード サンプルは、hTempThread が指す実際のスレッド オブジェクトに対して、その参照カウントをインクリメントしてすぐにデクリメントする以外に何かを行いますか?
質問 3: 質問 2 に対する答えが「いいえ」であると仮定すると、スレッドの参照カウントを必要に応じて 0 に減らすことができるように、ThreadFactory 実装によって生成されたスレッドを格納する効果的な方法は何ですか? これらの参照を削除するための適切な構文は何ですか? 以下のコード サンプルは、関連するすべてのオブジェクト (mvThreadsVector、tempThreads、mvThreadsVector によって追跡される各スレッド オブジェクト) の参照カウントを効果的に 0 に減らしますか? clear() は arraylist に格納されたオブジェクトの参照カウントに対して正確に何を行い、配列参照を null に設定すると内部に格納された要素の参照カウントに対して何を行うのでしょうか?
上記の質問のいずれかまたはすべてについての助けをいただければ幸いです。
inversion-of-control - 抽象ファクトリによって作成されたオブジェクトに対してioc.release()を呼び出す必要がありますか?
私は単純なダイアグラムエディタを持っており、IoCとDIに関する本を読んだ後、それらが提供する助けを借りてコードを切り離そうと決心しました。ユーザーがダイアグラムアイテムをダイアグラムに追加すると、アイテムは抽象ファクトリによって作成され、アイテムの内部ダイアグラムリストに追加されるように見えます。しかし、ユーザーがdiargamからアイテムを削除したい場合はどうすればよいでしょうか。まず、内部リストからアイテムを削除する必要があります。それでは、IoC.Release(Item)かどうかについて誤解がありますか?IoC.Release(Item)を呼び出さない場合(オブジェクト内のIoCの知識を回避)、IoC内のItemで何が起こったか。
PS:私はキャッスルウィンザーを使おうとしています
oop - 継承階層でオブジェクトを作成するための単一または複数の抽象ファクトリ?
次のヘルス クラブのシナリオがあります (C++ BTW でコード化されています)。
ランダムな Guest オブジェクトと Trainer オブジェクトを作成したい (そのため、どちらもランダムに生成された名前になりますが、ゲストの健康データもランダムになります)。
さまざまな複雑さのさまざまな乱数発生器をたくさん作成できるようにしたいと考えています。
したがって、両方ともランダムな姓/名ジェネレーター機能が必要であることは明らかですが、このコードを 1 か所に保持する方法がわかりません。
ランダムな生成を必要とするすべてのオブジェクトが使用できるすべての生成メソッド (たとえば、generateForename()) を含む抽象ファクトリを作成できます。しかし、トレーナーは、健康データとは関係なくても、健康データを生成できる工場にアクセスできる必要がありますか?
また、クラスごとに抽象ファクトリを用意することも考えました。1 つは人用、1 つは顧客用、1 つはゲスト用で、オブジェクトに適切なファクトリを渡してスーパークラスを生成させますが、状況によっては複雑すぎるように思えます。
私はこれにかなり慣れていないので、私のデザインが少しずれている場合はご容赦ください。
あなたたちは何を提案しますか?
dependency-injection - 複雑な階層に実行時の依存関係を注入するための抽象ファクトリ
次のクラス階層が与えられた場合
- ClassAにはClassBが必要
- ClassBにはClassCが必要
次のような依存関係グラフを取得します。
したがって、DI を使用する場合、ClassC を ClassB に、ClassB を ClassA に注入します。
しかし、ClassC が実行時の依存関係 (たとえば、ある種の戦略) であるとしましょう。実行時の依存関係を注入する方法として提案されているのは、
これで、ClassCFactory を ClassB に注入して、次のグラフを取得できます
これで ClassB にメソッドができました。このメソッドを呼び出して、ファクトリに作業を行わせることができます。例えば
しかし、今回のアプリケーションでは、ClassB について何も知りません (おそらく、さらにいくつかの層が関係しています)。解決策の 1 つは、ClassA に SelectC を配置することです。
または、単にデメテルの法則に違反して、次のようなことを行います
2 番目の解決策が適切ではないことは誰もが認めると思います。しかし、最初の解決策にはいくつかの欠点もあります。特に、中間層が多い場合はなおさらです。
ファクトリを 1 レベル引き上げて ClassB を作成することもできますが、ClassB は本当に実行時の依存関係なのでしょうか? どのような解決策を提案しますか? それとも、クラスの設計が悪いのでしょうか?
私見は、必要なオブジェクトを作成するファクトリではなく、オブジェクトが実際に作業を行うために必要なものに依存することを常にお勧めします。しかし、この考えを念頭に置いて、DIコンテナは役に立たないでしょう...