Vij*_*ede 5 android design-patterns architectural-patterns
根据干净的架构,设计Interactor是包含所有业务逻辑的部分.Interactor一词对我来说很困惑.在我看来,Interactor喜欢在数据和演示者这两个不同的层之间进行交互.
这是正确的术语吗？任何人都可以清楚Interactor的目的吗？它遵循哪种模式？如果Interactor不像我看来那么层层交互的设计模式是什么？
小智 9
Interactor是一种与"业务逻辑"概念无关的设计模式.没有深入细节,Interactor模式是Command模式的扩展; 每个"业务逻辑"对象都被视为"黑盒子",即为客户端执行的简单指令,将调用操作的对象与知道如何执行操作的对象分离.(参考参考书目以获得扩展说明).
在android环境中有一个简单的"规则",要求程序员在后台线程中执行长时间的任务,因此交互模式扩展了"命令模式",增加了一层线程.实现所有这些复杂的东西是为了创建一个"干净的架构",它需要一个可扩展,可维护和(可以说)可理解的代码.
关于这个问题..层层交互的设计模式是什么？根据具体情况,它可能有不止一个答案.您可以使用简单的接口作为入口点,因此您可以使用适配器模式,或者可能使用Facade模式,或者如果您想要执行更高级的操作,则可以实现事件总线系统.
资料来源:设计模式简单解释 - auth Alexander Shvets.第14页(适配器),第32页(命令),第47页(门面)
在干净的架构方法中，用例交互器是表达特定业务规则的层。用例交互器与实体（不可知的业务规则）交互以实现用例意图。实体可以在其他应用程序中使用，一旦它们是不可知论者，另一方面，用例交互器是特定的应用程序对象。
可以在 Robert C. Martin 的《Clean Architecture》一书中找到，第 20 章
如果您熟悉领域驱动设计，那么可以将交互器与应用程序服务进行比较。另外，“根据干净的架构，设计交互器是包含所有业务逻辑的部分”的说法是不正确的。相反，实体将包含业务（与应用程序无关的）逻辑；而交互器将包含特定于应用程序的逻辑。交互者会调用实体来实现用例，其中用例可能类似于创建采购订单。
回到 Robert Martin（Bob 叔叔）在他的培训视频《架构、用例和高级设计》中使用的清洁架构术语，Bob 叔叔说道：
交互器是特定于应用程序的。这意味着任何特定于应用程序的业务规则都属于交互器内部。交互者通过调用实体内与应用程序无关的逻辑的特定于应用程序的逻辑来实现其目标。例如，
CreateOrderInteractor调用 的构造函数和GetId方法OrderEntity。显然，这两种方法与应用程序无关。交互者知道如何调用这两个方法来实现用例的目标。
根据您的观察，Interactor 似乎是在数据和演示者等两个不同层之间进行交互，该工作实际上属于Boundary. 位于Boundary输送机制和Interactor，其中交付机制可能是桌面应用程序、MVC 应用程序、API 等。这使实际应用程序和业务代码保持分离，并且可以从一种交付机制转移到另一种交付机制。
他还在“附加”部分提供了一个很好的图表，显示了您购买视频后的互动。它看起来像下面这样：
Delivery Mechanism ==> Boundary ==> Interactor ==> Entity
PS 上面引用的视频非常有趣且信息丰富。