将线程逻辑与业务逻辑解耦

Decoupling threading logic from business logic?

本文关键字：解耦 业务 线程      更新时间：2023-10-16

将线程逻辑与业务逻辑耦合是常见的做法吗?我在考虑测试驱动的开发，想知道测试与线程逻辑绑定的业务智能是否有好处/缺点。考虑以下内容，

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;

这样做有什么好处/缺点吗?是否可以使用相同的方法将业务逻辑与其他通用设计模式解耦?

线程和其他计算效果往往会让单元测试作者感到头疼。如果可以，将线程管理封装在被测业务逻辑之外。

如果你正在寻找如何做到这一点的想法，考虑创建一个类型来表示线程可能完成的工作(该类型可以是Functor，成熟的类或可能只是函数指针)。

将"纯"业务逻辑置于该"可运行"类型的实例中，并在此接口上进行测试。然后，您可以实现一个可重用的线程池，它(比如说)接受队列中的这些可运行项并执行每个可运行项。这种模式可能有许多变化;我建议在boost库中查找现有的实现。

这种分离通常会而不是使您免于同步的负担，这通常是一个横切问题。锁有一种溜进原本干净的业务逻辑的方式。您可以尝试通过模拟它们来处理它们，或者尝试通过序列化访问(例如使用专用的"代理"线程和可运行程序队列)来完全消除锁定。

相关文章：