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、成熟的类或者可能只是一个函数指针。）

将您的“纯”业务逻辑放在这种“可运行”类型的实例中，并在此接口上对其进行测试。然后，您可以实现一个可重用的线程池，该线程池（例如）接受队列中的这些可运行对象并执行每个。这种模式的许多变化是可能的；我建议查看 boost 库以找到现有的实现。

这种分离通常不会让您摆脱同步的负担，这通常是一个横切关注点。锁有一种滑入其他干净的业务逻辑的方法。您可以尝试通过模拟它们来处理它们，或者尝试通过序列化访问来完全消除锁定（根据具体情况），例如使用专用的“代理”线程和可运行的队列。

于 2013-03-29T00:53:43.700 回答