2

スレッド ロジックとビジネス ロジックを結合するのは一般的な方法ですか? テスト駆動開発を念頭に置いて、スレッド化ロジックに関連付けられているビジネス インテリジェンスをテストする利点/欠点があるかどうか疑問に思っています。次のことを考慮してください。

class Thread { ... }
class FooThread : public Thread {
  /* business intelligence coupled to threading */
}

また、

class Thread { ... }
class Foo {
  ...
  /* once again coupled */
  Thread th;
}

これらのアプローチは、クラスをテストする際に依存関係を抽象化しようとすることに多少反対しているようです。代わりに、おそらくテンプレートを使用して、スレッドから完全に分離してインスタンス化できるクラスを設計することは可能/受け入れられるでしょうか?

template<class SomeFooClass>
class Thread { ... }

class Foo { 
  /* this class can be tested separately */
}

typedef Thread<Foo> FooThread;

これには利点/欠点がありますか？これと同じアプローチを使用して、ビジネス ロジックを他の一般的な設計パターンから切り離すことはできますか?

4

1 に答える 1

2

スレッドやその他の計算上の影響は、単体テストの作成者にとって頭痛の種になる傾向があります。可能であれば、テスト中のビジネス ロジックからスレッド管理をカプセル化したままにします。

それを行う方法についてのアイデアを探している場合は、スレッドが実行する可能性のある作業を表す型を作成することを検討してください (この型は、Functor、本格的なクラス、または単なる関数ポインターである可能性があります)。

この「実行可能な」タイプのインスタンス内に「純粋な」ビジネス ロジックを配置し、このインターフェイスでテストします。次に、(たとえば) これらのランナブルをキューで受け入れてそれぞれを実行する、再利用可能なスレッド プールを実装できます。このパターンには多くのバリエーションが可能です。ブースト ライブラリを調べて、既存の実装を見つけることをお勧めします。

この分離によって一般的に回避できないのは、通常、分野横断的な懸念事項である同期の負担です。ロックには、他の点ではクリーンなビジネス ロジックに滑り込む方法があります。それらをモックアウトして対処しようとするか、専用の「ブローカー」スレッドとランナブルのキューなどを使用してアクセスをシリアル化することにより (ケースバイケースで) ロックを完全に排除しようとすることができます。

于 2013-03-29T00:53:43.700 に答える