1

私は取引アプリのジュニア開発者です...注文更新検証ユニットがあります。交換からの注文確認を確認する必要があります。交換するために、さまざまなリクエスト (NEW、MODIFY、CANCEL) をまとめて送信します...検証は、すべての注文の T 間隔ごとに最大 N 回発生する必要があります。N 再試行する前にすべての注文の検証が成功した場合は問題ありません。それ以外の場合は、検証が失敗したことを示す必要があります。私は以下のように非常に緊急に行われた基本的なコーディングを行いました

for( N times )
{
   for_each ( sent_request_order )   // SENT
   {
       1) get all the  refreshed order from DB or shared mem i.e REFRESHED
       2) find current sent order in REFRESHED 

       if( not_found )
            not refreshed from exchange, continue to next order

       if( found )

       case NEW :    //check for new status, mark verification done
       case MODIFY : //check for modified status.. 
                     //if not mark pending, go to next order, 
                     //revisit the same after T time
       case CANCEL : //check for cancelled status.. 
                     //if not mark pending, go to next order, 
                     //revisit the same after T time
   }

   if( all_verified )
       exit from verification.

   wait ( T sec )

}

order_verification_pending、order_verification_done、order_visited、order_not_visited、all_verified、all_not_verified ... 表示に使用されるブール値フラグの多く..

これを行うためのより良いアプローチはありますか....クラス間で責任を分割します.????

これは一般的な質問ではないことはわかっています....しかし、それでもフラグのせいで扱いが面倒です...

4

2 に答える 2

1

あなたのアルゴリズムは実行可能に見えます。実装します。

コードが機能するようになる前に、コードを最適化しようとしないでください。動作するバージョンを実行したら、どんなに醜いことでも気にせず、最適化の方法と手段を検討します。フラグを処理する方法が見つかる可能性は十分にあります。

于 2010-12-21T06:37:55.210 に答える
0

あなたは「order_verification_pending、order_verification_done、order_visited、order_not_visited、all_verified、all_not_verified」について話します...しかし、それはブール値の数を2倍にしているようですorder_visited. !order_visited. 関係する状態が 2 つ以上ある場合はenum、複雑でオーバーラップする多数のブール値ではなく、 を使用します。たとえば、検証が保留中、完了、失敗などである可能性があるが、これらがすべて相互に排他的である場合、単一の現在の状態をその に保存しenumます。

保留中の操作のセットを用意し、セットが空になるか検証全体がタイムアウトするまで、そのセットから要素を削除する方がエレガントです。そうすれば、すでに成功したことがわかっている操作をチェックしていません。

于 2010-12-21T06:48:07.570 に答える