問題タブ [factory-method]

これは不可能だと 70% 確信していますが、サブクラスに特定のコンストラクターまたはファクトリー メソッドがあることを確認する方法はありますか?

この場合、StringSerializableサブクラスに次のメソッドが必要なを作成しようとしています

• toString、オブジェクトを に変換しますString。
• fromStringからインスタンスを取得しますString。

明らかに、最初のケースでは、toString抽象化できます。一方、静的でfromStringないことには問題があるようです。ただし、抽象静的メソッドを作成できません。また、コンストラクターが完全に適切であるとは思いません。

[[self alloc] init] ファクトリ メソッドを記述するときの の使用法を理解するのに苦労しています。ファクトリ メソッドは、クラスのインスタンスを作成する便利なメソッドであり、alloc、init、およびautoreleaseを実行することを理解しています。これがどのように形成されるかを見ることができます。たとえばNSArray、ファクトリ メソッドarrayWithArray:、またはarrayなどを使用してプロパティを宣言し、それをセットアップするために呼び出されます。allocこれがandへの完全な (明示的な) 呼び出しとどのように異なるかは明らかinitです。

これに関する私の問題は、ファクトリメソッドをより深いレベルで理解していないことです。alloc明示的に呼び出す代わりにinit、クラスファクトリメソッドを使用して基本的に次のようなものをカプセル化できるという説明をオンラインで見つけました。

しかし、サブクラスがクラス ファクトリ メソッドを使用できるようにするには、どうすれば効果的でしょうinstancetypeか?[self alloc]

とにかく、このクラスのインスタンスを作成できないようです。abstract が宣言されているためですが、同時に、静的ファクトリ メソッドが IntBuffer allocate(int capacity)あり、単純にインスタンスを作成できますBuffer b=IntBuffer.allocate(128) が、待機してください。IntBuffer は抽象的であり、持っていません。定義済みの具象サブクラス。これはどのように機能しますか？

編集 - - - - - - -

IntBuffer のサブクラスを返すのではないかと疑っていましたが、HeapIntBuffer やそのようなサブクラスが見つかりませんでした。内密に宣言してるのかしら?? したがって、 api doc にはありません!

私は..としてファクトリメソッドを持っています

今、別のサービスメソッドからこのメソッドを呼び出すと..

エラーが表示されます..Uncaught TypeError: undefined is not a function. 誰でもこのエラーを解決するのを手伝ってください..

のインスタンスで実行されている操作Add/のロギング用に設計された次のアーキテクチャを検討してください。UpdateEntity

LogFactoryは であり、 を使用しておよびコンストラクタを介してAbstract Factory2 つのファクトリを受け取ります。を生産するためのコンクリート工場と実装の両方。どちらもログ可能なデータを収集する必要があります。さて、すべてが明確になり、これまでのところパターンが正しい解決策であることを認めていただければ幸いです。AddUpdateDIAddLogFactoryUpdateLogFactoryILogFactoryILogEntityAbstract Factory

問題：

UpdateLogFactory追加のデータが必要なため、例外です:ModifiedProperties前/後の文字列を作成します (一方、その兄弟、つまり実装している他の型ILogFactoryは、この種のデータを必要としません; でEntity十分です)。を壊さないようにするために、そのコンストラクターを介しILogFactoryて に渡すことにしました。それは私の問題を解決しますが、私はどういうわけか不正行為をしているように感じます。私は他の人に似ているふりをしていますが、実際にはそうではありません。ModifiedPropertiesUpdateLogFactoryUpdateLogFactory

誰かがUpdateLogFactory別の具象型に置き換えたい場合、それが必要であることをどうやって知るのModifiedPropertiesでしょうか?

Head First Design Patterns の本を読んでいて、第 4 章の「ファクトリ メソッドの宣言」セクションで、メソッドは保護されていると宣言されています。

これは私を混乱させます。なぜなら、私は当初、ファクトリ (メソッド) を使用することでインスタンスを作成する単一の場所を持つことができると考えていたからです。 "。「行動する」とはpizza.cut()etc を意味し、「クエリを実行する」とは を意味しpizza.isSpicy()ます。

protectedキーワードは、クエリをサブクラスと同じパッケージ クラスのみに制限しませんか? サードパーティのクラスが注文前にピザが辛いことを知る必要があるとしたら?

ハイライトボックスにはそうあるべきだとは書かれていませんprotectedが、サンプルコードにはあります。

Factory Methodパターンを実装していましたが、いくつかの例をチェックして、抽象クラスまたはインターフェースを作成する代わりに製品の具象クラスを拡張することが正しいかどうかを判断できませんでした...これは単なる例です(PHP) .

したがって、抽象ファクトリとその具体的なファクトリがあります。

すべての例で見たのは、通常、製品は抽象クラスまたはインターフェースから拡張されているということですが、テストを行っているときに、私の場合はその必要がないことに気付きました。必要なのは、一般的な動作と残りのサブクラス。

クラスのインスタンス化はまだサブクラスに派生しているため、これはファクトリ メソッドの実装であると本当に信じていましたが、この方法で別のサンプル コードを見つけることができました。

質問: これはまだファクトリ メソッドの実装ですか? そうでない場合はなぜですか？

静的関数呼び出しを必要とする呼び出し環境を変更せずに継承を使用するようにテンプレート クラスを書き直しますが、静的関数を仮想にすることはできません。

この質問は、C++ コーディング テストで見つけました。実際、この質問はそれほど明確に述べられておらず、これまでのところ解決策がありません。あいまいで申し訳ありません。誰でもこの質問をよりよく理解できるように。以下は私の個人的な解釈です。私の誤解を指摘していただきありがとうございます。

このテンプレート クラスは、サーバー側でカプセル化されたライブラリであり、静的関数などの一部の API はクライアント側で呼び出されます。ただし、静的関数を仮想にすることはできません。つまり、静的関数には動的境界 (オーバーライド) は許可されません。

1. テンプレート クラスを書き直そうとすると、このクラスは継承を使用します。したがって、このクラスには派生クラスがあります。しかし、API 呼び出し環境を変更したくありません。つまり、サーバー側のコードをアップグレードする予定ですが、クライアント側のコードを変更したくありません。

2. テンプレートクラスを書き換えるために、継承を使用してみてください。しかし、API 呼び出し環境を変更したくありません。つまり、サーバー側のコードをアップグレードする予定ですが、クライアント側のコードを変更したくありません。

1 と 2 のどちらが正しい解釈かはわかりません。しかし、私はより 1 に傾いています。私の意見では、この質問は主に次の概念をテストします。

1. サーバーサイドでのコードメンテナンス
2. ファクトリーメソッドを中心としたデザインパターン
3. クラス継承で静的関数をオーバーライドするためのトリック

サーバー側の元のコード:

クライアント側の呼び出し環境:

出力：

私は基本クラスです

(明らかに、静的関数のオーバーライドはありません)

/////////////////////////////////////////////// /////////////////////////////

サーバー側でコードを書き直しました：

クライアント側の呼び出し環境:

出力：

私は基本クラスです

私は派生クラスです

私の修正：

1. 静的関数を「オーバーライド」するには、トリックとして静的関数を呼び出す仮想関数を追加します。
2. ファクトリ メソッドを使用して、インスタンスの作成をクライアント側から隠します。

しかし、そのような変更が呼び出し環境を変更しないという要件を満たすことができるかどうかはわかりません。クライアント側でAPI呼び出しを変更するためです。私の努力に基づいて、それが私の最善の解決策です。コメントと改善を大いに感謝します。

複数の複雑なオブジェクトを作成できるファクトリを実装する必要があります。依存性注入でどのように処理する必要がありますか?

特にMark Seemannのトピックについては、stackoverflow（および他の場所）ですでに多くのトピックを読んでいますが、決定を下すことはできないため、意見が必要です。

例えば：

いくつかの解決策を見つけましたが、どれを選択すればよいかわかりません。

1. 解決策は、例のように、依存関係をインスタンス化する責任をファクトリに与えることです。

問題点: 依存性注入を使用しない場合と同じ問題。

2. もう1つは、ファクトリーコンストラクターに依存関係を与えることです

問題: コンストラクターには多くのパラメーターがあり、リストが大きくなる可能性があります。

3. 私がインターネットで見つけた 3 番目の解決策は、イベントの代わりに一種のビルダーを作成することです。ファクトリは、作成するオブジェクトの種類を把握する責任を負い、ビルダーはそれらの作成方法を把握します。

問題: ビルダー DP の役割は依存関係を処理することですか? 解決策 1 と同じ問題が発生するのではないかと心配しています。

私たちは何をすべきか ？

ベン

私は、実際のクラスの実装をインターフェイスの静的フィールドに保持するプロジェクトに取り組んでいます。これの一例は次のとおりです。

これは、IoC フレームワークを使用する際の複雑さを回避し、コードに のような呼び出しを散らかさないようにするためcontext.getImpl(Storage.class)です。さらに、インターフェイスの静的フィールドに実装参照を保持することで、大きなファクトリ クラスを導入することを回避するためにもこれを行います。これで達成できることは、何かを保存する必要があるアプリケーションのすべての部分がStorage.instance.create(File f).

ただし、これが広く受け入れられている「原則」に反するかどうかについては議論してきました。初めに; インターフェイスで実装の依存関係を作成するのに問題がありますか? 厳密に言えば、インターフェイスは実装への直接の「参照」を持つようになりました。第二に、インターフェイスの static フィールドが final フィールドであるため、テストが単に aMemoryDiskStorageまたは aを「注入」できないことを認識しています。MockDiskStorageどうすればこれを回避できますか?