1

まず、Objective-Cを使用していますが、これはまったく問題ではありません。

私の状況は次のとおりです。

2つの異なるシナリオがあります。私はそれらを次のようなプリプロセッサマクロで区別します。

#ifdef USER
    do some stuff for scenario 1
#else
    do some stuff for scenario 2

どちらのシナリオも、アプリケーション全体のアイテムのリストで機能しますが、違いはそれらのアイテムを取得する方法です。

最初のものでは、サーバーにリクエストを送信してアイテムを取得します。

2つ目は、ローカルデバイスストレージから取得します。

私が今持っているのは、実装された2番目のシナリオです。ローカルストレージからアイテムを取得することでアイテムのリストを返すシングルトンクラスがあります。（従来のデータベースシングルトンのように）

他のシナリオを追加したいと思います。アイテムはアプリ全体のどこからでも取得できるので、これもシングルトンにしたいです。

シングルトンスーパークラスと、アイテムを取得するさまざまな方法を実装する2つのサブクラスを持つことは理にかなっていますか？シングルトン階層は私にはかなり奇妙に聞こえます。

4

2 に答える 2

1

それは正確には階層ではありません。あなたが言及しているスーパークラスは、実際には2つの具象クラスのインターフェースであり、必要に応じてシングルトンにすることができます。インターフェイスは抽象的なエンティティであるため、インスタンス関連の用語はそれとは無関係です。

プリプロセッサを使用してシナリオの選択を行うことにより、プログラムの動作を静的に定義しています。このアプローチに固執し、それが要件に適合する場合は、デザインパターンは必要ありません。コードでは、静的にインスタンス化されたデータへのポートである、上記のインターフェイスを使用するだけです。より柔軟性が必要な場合（これは可能性が高いと思われます）、実行時にシナリオの選択を行うことができます。この場合、シナリオを適用するための戦略パターンとインスタンス化のためのファクトリパターンが役立つ場合があります。

于 2012-12-07T10:29:58.163 に答える
1

ストラテジーと組み合わせたファクトリー。

コンストラクターだけを使用するのではなく、別のクラスを使用してインスタンスを作成するパターンとしてのファクトリ。あなたはすでにあなたのシングルトンでそれをしている可能性が高いです。

どの種類のオブジェクトがrutimeにファクトリによって実際に作成されるかを構成する機能の戦略。

于 2012-12-07T10:25:30.853 に答える