3

Joubert によるこのブログ投稿は、私の目を開かせてくれました。私は Java やその他の言語で多くのデザイン パターンを扱ってきました。しかし、Objective-C はかなりユニークな言語です。

プロジェクトで、Dropbox や Facebook などのサードパーティ API とやり取りするとします。私がこれまで行ってきたことは、サードパーティ API に関係するすべてのものをシングルトン クラスに結合することです。したがって、View Controller のどこからでもクラスにアクセスできます。たとえば、次のようにします。[[DropboxModel sharedInstance] uploadFile:aFile]

ただし、ブログ投稿で指摘されているように、これは効率的ではなく、スパゲッティ コードや不適切な単体テストにつながります。では、モジュール式で使いやすいようにシステムを設計する最善の方法は何でしょうか?

4

3 に答える 3

2

シングルトンがスパゲッティ コードにつながり、非効率的であるという考えには異議を唱えます。ただし、単体テストの問題は正当であり、シングルトンは実際には単なる派手なグローバル変数であるため、モジュール性を低下させます。

アプリデリゲートからコントローラーにシングルトンインスタンスを注入するというJoubertのアイデアが好きです（それ自体がシングルトンです）。同じアプローチがあなたのために働くと思います。

単体テストで別のスタブ オブジェクトを使用したい状況で通常行うことは、API を表すプロトコルを定義し、「実際の」API オブジェクトをそれに準拠させ、スタブ API オブジェクトも準拠させることです。単体テストではスタブを使用し、アプリでは実際のオブジェクトを使用します。

于 2011-02-03T15:33:58.670 に答える
0

これにより、シングルトンに関連するアーキテクチャ上の問題が実際に解決されるわけではありませんが、読みやすさと入力可能性のために、DropboxModelヘッダーファイルでいつでもマクロを定義できます。例：

#define DBM [DropboxModel sharedInstance]

<...>
[DBM uploadFile:aFile];
于 2011-02-03T20:16:27.273 に答える
0

私は通常、抽象化レイヤーを作成します。これにより、使用するライブラリの呼び出しに単純なインターフェイスがラップされ、必要な状態 (変数など) を導入する機会が与えられます。

次に、必要なものと使用するものだけを公開し、独自の状態とチェックを追加して、ライブラリのすべての問題を 1 か所から簡単に処理できます。「問題」は、いくつかの理由で導入される可能性があります。それは、スレッド化、リソース、状態、またはバージョン間の望ましくない動作の変更である可能性があります。

ほとんどのライブラリは、シングルトン経由でのみ使用することを意図していません。そのような場合は、通常どおりにインターフェイスを作成するのが (主観的に) 最善です。もちろん、抽象化レイヤーの背後にある制約に注意してください。その意味では、サイズ/タスク/目的/機能によって分割されたオブジェクト ベースのインターフェイスを作成するだけです。これはすべて、独自のクラスを作成するときに通常行うことです。

あちこちにライブラリが必要ない場合は、依存関係を最小限に抑えるために必要なものをラップすることも良いと思います（大規模なプロジェクトではますます重要になります）。

ライブラリをいたるところで使用する場合は、抽象化レイヤーなしで呼び出しを使用することもできます。

于 2011-02-03T22:21:51.863 に答える