1

ARC を使用して、オンライン XML ファイルのデータを解析するアプリケーションを作成しました。1 つのクラスと 1 つの API 呼び出しを使用して、必要なものすべてを取得できます。API は XML データを提供します。xml ファイルが大きいため、このクラスには多数の変数、IBOutlets、および IBAction が関連付けられています。

しかし、これには 2 つのアプローチがあります。

1) XML データを解析し、そのデータをアプリケーションに実装するクラスを作成します。つまり、すべてを実行する 1 つのクラスを作成します (既に行ったように)。

また

2) XML データを解析するクラスを作成し、XML パーサー クラスから取得したデータを処理する他のクラスを作成します。つまり、1 つのクラスが解析を行い、別のクラスがそのデータを実装します。

XML データを提供する一部の API は、サービスへの呼び出し/分または呼び出し/日の数を追跡することに注意してください。したがって、複数のクラスが API を呼び出す必要はありません。必要なすべてのデータを受け取る API に対して 1 つの要求を行う方がよいでしょう。

では、xml データを処理するためにいくつかの小さなクラスを使用する方がよいのでしょうか?それとも、1 つの大きなクラスを使用してすべてを実行しても問題ないでしょうか?

4

2 に答える 2

2

疑問がある場合は、少人数のクラスの方が優れています。

2) XML データを解析するクラスを作成し、XML パーサー クラスから取得したデータを処理する他のクラスを作成します。つまり、1 つのクラスが解析を行い、別のクラスがそのデータを実装します。

これの重要な利点の 1 つは、後者のクラスがモデル化するものが、前者のクラスが行う解析作業とは別であることです。これが重要になります：

  • Peter Willsey が言ったように、XML パーサーが変更されたとき。たとえば、ストリーム ベースの解析からドキュメント ベースの解析に切り替える場合、またはその逆の場合、またはある解析ライブラリから別の解析ライブラリに切り替える場合です。
  • XML 入力が変更されたとき。新しい形式または形式の新しいバージョンのサポートを追加したい場合、または廃止された形式のサポートを無効にしたい場合は、単純に解析クラスを追加/削除できます。モデル クラスは変更しないままにすることができます (または、新しい/改善された形式で新しい機能をサポートするために、小さくて明白な改善のみを受け取ることができます)。
  • 非 XML 入力のサポートを追加する場合。たとえば、JSON、plist、キー付きアーカイブ、独自のカスタム形式などです。繰り返しますが、解析クラスを簡単に追加/削除できます。モデル クラスを大きく変更する必要はありません。

これらのことがまったく起こらなくても、一緒にマッシュアップするよりも分離したほうがよい. 入力の解析とユーザー データのモデリングは、2 つの異なる仕事です。それらを一緒にマッシュアップすると、それらを個別に推論することが困難または不可能になります. それらを別々にしておけば、他のステップを踏むことなく一方を変更できます。

于 2012-04-26T01:06:51.573 に答える
1

用途によると思います。考慮すべきことは、使用している XML パーサーを変更する必要がある場合はどうするかということです。モノリシック クラスを書き直す必要があり、多くの無関係な機能が壊れる可能性があります。XML パーサーを抽象化した場合、その特定のクラスの実装を書き直すだけで済みます。または、アプリケーションのスコープが変更され、突然複数のビューが作成された場合はどうなるでしょうか? DRY (Don't Repeat yourself) の原則に違反することなく、他の場所でコードを再利用できますか?

努力したいのは、低結合と高結束です。つまり、クラスは互いに依存してはならず、クラスは高度に関連するメソッドで明確に定義された責任を持つ必要があります。

于 2012-04-25T21:42:15.827 に答える