责任链设计模式是否适合在硬件组件上运行的 Python 解决方案答案

【问题标题】：Is chain of responsibility design pattern suitable for Python solution operating over hardware components责任链设计模式是否适合在硬件组件上运行的 Python 解决方案
【发布时间】：2018-12-19 17:12:40
【问题描述】：

我有一个用 Python 编写的 OOP 解决方案，主要专注于管理不同类型的硬件组件，例如摄像头、伺服、接近传感器等。

我拥有的是一群运营经理。操作管理器基本上是一个类，其中定义了多个公共方法。我定义的规则如下：

1. Different operation managers can call each other’s public methods
2. Multiple operation managers are involved into one specific use-case
3. Operation manager's method execution depends on the result of the previous operation manager (if previous was successfully executed - execute this one, otherwise terminate)
4. Each operation manager must be able to report its failure to a common channel (logging)
5. There’s no need for a transactional behavior (rollback)

我在这里的目标是能够

轻松集成新的运营经理
能够测试特定用例（一组操作管理器操作）
引入一定程度的抽象，让不同的运营经理相互解耦。

我一直在关注CoR，但仍然不确定它是否是我的最佳选择。

【问题讨论】：

标签： python design-patterns raspberry-pi chain-of-responsibility

【解决方案1】：

不。责任链对于逐步处理某事很有用，其中每个组件可能会或可能不会参与，或者可能会或可能不会终止整个执行。它描述了“步骤”的线性排序，并且通常根据“链接”的链表实现 - 负责处理特定数据的特定对象。 HTTP 拦截器是典型的例子。对于非线性-线性排序，使用了一个图，它与GoF 的责任链关系不大：“很少”，因为链表本质上是一种图。

您所描述的内容过于宽泛，无法指定特定模式。它可以通过很少的模式来解决，具体取决于代码复杂性、外部依赖项、用例数量和许多其他因素。

既然您以use case 原语为中心，为什么不在您的代码中严格定义它呢？ UseCase 接受它需要的任何内容并输出某种统一形式的结果 - 您必须引入通用的结果/故障报告对象，该对象足够通用，可以被所有用例重用。

我所描述的不是模式，至少不是GoF 模式，但绝对是满足您的要求和期望的一个很好的起点。

【讨论】：