2

私は、同じインターフェイスを介して任意の支払いプロセッサを実装できるようにする支払いライブラリに取り組んでいます。私が今抱えている問題は、データがプロセッサに供給される方法を改善したいということです。現在、それは配列であり、その配列には満足していません。問題は、すべてのフィールドを事前に把握していないと、通知が表示されたり、プロセッサ コード自体に膨大なチェックが必要になったりすることです。アイデアは、アプリケーションによって異なるため、あらゆる種類のデータ構造を取り、プロセッサで動作させるだけでなく、プロセッサが必要なデータフィードを確実に取得できるようにすることです。

私の考えは、それをオブジェクトに変更することです。オブジェクトには、すべてのプロセッサが必要とし、通常は共通の限られたフィールドのセットが付属していますが、オブジェクトを拡張して追加のフィールドを取得することもできます。

その利点は、プロセッサで支払いオブジェクトが渡されたことを検証できることと、例外をスローしない場合でも、すべての必須フィールドを実装しているかどうかを検証できることです。

問題は、これが良いアプローチであるかどうか、またはすべてのプロセッサが渡されたデータに依存できることを確認するためのより良いフェイル セーブ方法があるかどうかです。

4

4 に答える 4

1

あなたの場合、次のようなアーキテクチャを使用する可能性があります。

クラスpayment_data-> このクラスにはすべての共通フィールドがあり、いくつかの共通データ検証を提供する可能性があります。特定のプロセッサがプロセッサ固有のロジックの追加データを受け入れることができる特定のプロセッサ固有の実装でこれをサブクラス化することもできます。検証ルールに従って正常に構築できなかった場合、このオブジェクトを支払い処理ロジックに渡す必要さえありません。

インターフェイス-> このインターフェイスは、プロセッサ固有の実装クラスのいずれかが基本オブジェクトpayment_processorを処理できるようにする必要がある共通のメソッドを定義します。payment_data

プロセッサ固有のクラスの実装payment_processor-> これらのクラスはすべて基本的なオブジェクトを処理できますが、オプションで、そのプロセッサの追加機能を実装payment_dataするプロセッサ固有のサブクラスを渡すことができる場合があります。payment_data

于 2012-12-18T00:20:55.980 に答える
1

私はあなたがやっていることを正確に行い、配列に固執しました。配列は、必要な「フィールド」が欠落しているかどうかを非常に高速にチェックします。配列キーがフィールド名である場合、必須フィールドの配列を作成し、それを使用して必須フィールドの存在をテストします。

function loadData($data) {
     static $rqd_fields = array('field1','field2','field3');
     $passed_fields = array_keys($data);
     $missing_fields = array_diff($rqd_fields, $passed_fields);
     if ( count($missing_fields)>0 ) {
         // error, return $missing_fields
     } else {
         // ok, continue
     }
 }
于 2012-12-18T00:22:07.027 に答える
0

オブジェクトは良いアプローチです。これは十分に一般的であるため、かなりの柔軟性が得られます。柔軟性を最大化するために、必ずインターフェイスにコーディングしてください。

もちろん、オブジェクトをどのように設計するかは重要です...

于 2012-12-18T00:15:05.540 に答える
0

あなたは正しい考えを持っています。インスタンス化するために必要なすべての要素の __construct を持つモデルを使用し、必要に応じてモデル (もちろんオブジェクト) を他の場所に注入することをお勧めします。このようにして、インターフェイスでさまざまなモデルを非常に簡単に使用できます。

于 2012-12-18T00:18:09.067 に答える