そのため、iOSアプリにAFNetworkingを使用しており、ネットワーク到達可能性コードを含めるために少しリファクタリングを行っています。リクエストなどのパラメータをマーシャリングするための以前のデザインパターンは、サービス固有のリクエストパラメータを作成し、それらを使用してNSURLを作成し、続いてNSURLRequestを作成することでした。
私が接続しているサービスはいたるところにあります—署名されたリクエスト、アクセストークン、混乱したビターズなどが必要なものもあります（Twitter、Foursquare、Instagram、Tumblrなど）。
サービスごとに、一般的なサービスに依存しないプロトコルに基づいて、ステータスを取得したり、ユーザーのプロファイルデータを取得したりできるメソッドがあります。これらのメソッド内で、AFHTTPClientを作成し、正常に動作します。
しかし、いくつかのアプリケーションセマンティクスを追加しているので[AFHTTPClient setReachabilityStatusChangeBlock：]さまざまなサービスリクエストを処理するクラスのインスタンスごとにAFHTTPClientを作成する必要があるのではなく、そのクラス内のメソッドごとに1つ作成する必要があるのではないかと思います。サービスリクエストを処理しますか？到達可能性ステータス変更ブロックを定義する
この場合に使用する適切なデザインパターンについて誰かが提案を持っていますか？つまり、何かを整理することはできますが、「ベストプラクティス」/「経験から構築された」パターンがあるのだろうかと思います。
一般に、特定のサービスからの要求を処理する私のクラスは長続きします。実行時にログインする「ユーザー」ごとに1つありますが、ユーザーの数は通常非常に少なく、数十になります。
私が求めているのは、一般的に、人々は一般的にAFHTTPClientをどこで定義し、ネットワーク到達可能性ステータス変更ブロックは一般的に何をするのかということだと思います。（本能によると、操作をキャンセルし、ステータスがインターネットがなくなったことを示している場合はユーザーに警告しますが、巧妙な「再試行」セマンティクスなどはありますか？）