問題タブ [singleton]

皆さん、私は非常に単純な iPhone アプリケーションを作成しています。データは plist ファイル (基本的には NSDictionary) から取得されます。これをシングルトン クラスにロードし、さまざまなビュー コントローラーで使用してデータにアクセスしようとしています。

これが私のシングルトンの実装です（このスレッドを大幅にモデル化しています）

したがって、アプリケーションの他の場所 (TableView デリゲートなど) で searchDict または searchArray プロパティにアクセスしようとすると、次のようになります。

*** -[NSCFSet objectAtIndex:]: unrecognized selector sent to instance 0x5551f0 という例外が発生します

objectAtIndex メッセージが NSCFSet オブジェクトに送信される理由がよくわかりません。シングルトンが間違って実装されているように感じます。前述のスレッドでアップルが推奨するような、より複雑なシングルトン実装も試しましたが、同じ問題がありました。あなたが提供できる洞察に感謝します。

つまり、デスクトップアプリケーションの場合。これは一般的な質問であり、一般的な回答のみが必要な場合があります。

これまでのすべてのプロジェクトで、シングルトン パターンを使用して、アプリケーション全体のアプリケーション構成にアクセスしていました。このパターンはテスト容易性を向上させず、コンポーネントの依存関係を隠すため、最近、シングルトン パターンを使用しないことを検討している多くの記事を目にします。私の質問は、構成オブジェクトをアプリケーション全体に渡すことなく、アプリケーション全体で簡単にアクセスできるアプリケーション構成を格納する最良の方法は何ですか?

前もって感謝します

マドゥ

「デモモード」を追加する必要がある WPF プログラムがあります。毎回プログラムを再コンパイルせずにデザイナーがデモ モードを変更できるようにしたいので、外部 XAML ファイルからストーリーボードを使用するのは良い考えだと思います。「デモ モード」は基本的に、アプリケーションの依存関係プロパティの一部をアニメーション化するストーリーボードです。

アプリケーションの DP を公開するために、アプリケーションのクラスの public static メンバー (シングルトン) を作成して、アプリケーションの DP を常に外部から利用できるようにしました。この場合、ストーリーボードはそれらにアクセスします。

外部 XAML ファイルに、アプリケーションの名前空間/アセンブリを正しく参照する適切な xmlns を追加しました。したがって、理論的には、ストーリーボードでアプリケーションの DP にアクセスできるはずです。

問題は、オブジェクトが XAML で宣言/名前付けされていない場合に、ストーリーボードで静的オブジェクトの DP をアニメーション化する方法がわからないことです。ストーリーボード アニメーション フレームを宣言する場合、ストーリーボードの添付プロパティはStoryboard.TargetNameとStoryboard.TargetPropertyだけです。

誰かが私を正しい方向に導くためのヒントを教えていただければ幸いです。

私はこのようなシングルトンを使用します：

私はこのような名前のないクラスを使用します：

シングルトンパターンには、読み取り可能なエラーメッセージがあること以外に、名前のないクラスに勝る利点はないように感じます。シングルトンの使用は、名前のないクラスオブジェクトを使用するよりも扱いにくいです。まず、クライアントは最初にインスタンスのハンドルを取得する必要があります。第二に、の実装者はSingleton::instance()並行性を考慮する必要があるかもしれません。

では、なぜ、どのようにして、名前のないクラスよりもシングルトンを選択するのでしょうか。

補遺として、名前のないクラスの明白な定義は

私はそれを次のように定義することもできます：

後者のアプローチには、読み取り可能なコンパイラエラーメッセージの利点がありますが、デバッグモードではシングルトンではありません。

Rails にサイトがあり、サイト全体の設定が必要です。アプリの一部で、特定のイベントが発生した場合に SMS で管理者に通知できます。これは、サイト全体の設定で構成できるようにしたい機能の例です。

だから私は設定モデルか何かを持っているべきだと思っていました. SMS 通知用に has_many :contacts できるようにしたいので、モデルにする必要があります。

問題は、データベースに設定モデルの投稿が 1 つしか存在できないことです。だから私はシングルトンモデルを使用することを考えていましたが、それは新しいオブジェクトが作成されるのを妨げるだけですか?

次のように、属性ごとに getter および setter メソッドを作成する必要がありますか?

Model.attribute を直接使用するのはおそらくベストプラクティスではありませんが、常にそのインスタンスを作成して使用しますか?

ここで何をすべきですか？

私が長年携わってきたプロジェクトでは、非常に役立つことが証明されているデザイン パターンを徐々に進化させてきました。私は時々それで少し福音的にならなければならないと感じますが、それが誰かの古い帽子の私の​​バージョンであることがわかったら、少し恥ずかしいです. 私は無駄にデザインパターンを掘り下げましたが、それについて話している人に出くわしたことはありませんが、私の検索は網羅的ではありませんでした.

コアとなるアイデアは、一連の定義オブジェクトを管理するブローカー オブジェクトを持つことです。各定義オブジェクトは、いくつかの複雑なプロパティの可能な値を構成します。例として、すべて EngineType を持つ Car、Plane、および Generator クラスがあるとします。Car は独自の EngineType オブジェクトを保存しません。車が持つエンジンの種類を示す何らかの種類の参照キー (整数または文字列 ID など) を保存します。たとえば、WankelEngine などの EngineType のプロパティまたは動作を調べたい場合は、EngineTypeBroker シングルトン オブジェクトに WankelEngine の定義オブジェクトを要求し、それに参照キーを渡します。このオブジェクトは、EngineTypes について知っておくべき興味深いことをすべてカプセル化します。単にプロパティ リストである可能性がありますが、動作が読み込まれる可能性もあります。

したがって、それが促進しているのは一種の共有された疎結合の集約であり、多くの車が WankelEngine を持っている可能性がありますが、WankelEngine 定義オブジェクトは 1 つしかありません (そして、EngineTypeBroker はそのオブジェクトを置き換えることができ、疎結合を強化された実行時のモーフィズムに活用します)。

私が使用するこのパターンのいくつかの要素 (引き続き EngineType を例として使用します):

1. 指定された値が EngineType の有効な参照キーであるかどうかを判断するための IsEngineType(x) 関数と、参照キーに対応する EngineType 定義オブジェクトを取得するための EngineType(x) 関数が常に存在します。
2. 特定の EngineType に対して常に複数の形式の参照キーを許可します。常に少なくとも文字列名と定義オブジェクト自体、多くの場合は整数 ID、そして場合によっては EngineType を集約するオブジェクト タイプを許可します。これはデバッグに役立ち、コードをより柔軟にし、私の特定の状況では、古い慣行と比較して多くの下位互換性の問題を緩和します. (このプロジェクトのコンテキストでは、人々がこれをすべて行うために使用する通常の方法は、EngineType が持つ可能性のある各プロパティのハッシュを定義し、参照キーでプロパティを検索することでした。)
3. 通常、各定義インスタンスは、その定義タイプの汎用クラスのサブクラスです (つまり、WankelEngine は EngineType を継承します)。定義オブジェクトのクラス ファイルは、/Def/EngineType のようなディレクトリに保持されます (つまり、WankelEngine のクラスは /Def/EngineType/WankelEngine になります)。そのため、関連する定義はグループ化され、クラス ファイルは EngineType の構成ファイルに似ていますが、コードを定義する機能があります (通常、構成ファイルにはありません)。

いくつかの自明なサンプル疑似コード:

それで、これに名前はありますか？

テストできないコードは、本当にイライラします。次のことが oo-code をテスト不可能にします:

• グローバルな状態、例: シングルトン デザイン パターン
• データベースアクセスなどの凝った作業を行う静的メソッド
• 深い継承ツリー
• 制御ステートメントなどのコンストラクターでの作業
• 単一責任原則に違反するクラス

さらに警告サインはありますか？