MVP模式项目中Interactor使用疑问：是否需要及能否拆分？

首先明确说：拆分两个独立的Interactor是完全可行的，而且是非常好的实践，完全符合MVP的设计思想和软件工程的单一职责原则。

1. 要不要使用Interactor？ #

当然需要！Interactor的核心作用就是把与UI无关的业务逻辑、数据操作从Presenter/View中抽离出来，让你的Activity（View层）只负责UI渲染、用户交互的响应，Presenter只负责协调View和业务逻辑/数据层的交互，而具体的“从数据库取数据”“执行数学计算”这类纯业务/数据操作，就该交给Interactor来做。

这样做的好处非常明显：

• 代码解耦：UI层和业务逻辑完全分开，以后修改数据库操作或者计算逻辑，不用动Activity/Presenter的代码
• 可测试性：Interactor里的逻辑可以单独写单元测试，不用依赖UI环境
• 复用性：比如以后另一个页面也需要做同样的数学计算，直接复用这个Interactor就行

2. 拆分两个Interactor是正确的选择 #

你担心“每次只用50%功能”是不良实践，这恰恰说明把两个功能放在同一个Interactor里才是反模式。

软件工程里的单一职责原则（SRP）告诉我们：一个类/组件应该只负责一个单一的功能，只有一个引起它变化的原因。你的两个功能：

• 数据获取：负责和本地数据库交互，属于数据访问类的操作
• 数学计算：属于纯业务逻辑的计算，和数据存储完全无关

如果把它们塞进同一个Interactor，这个类就会变得臃肿，以后修改数据库逻辑可能会影响计算逻辑，反之亦然；而且当你只需要其中一个功能时，不得不带着另一个不需要的代码，既增加了冗余，也不利于复用。

拆分后，DataFetchInteractor和MathCalculationInteractor各自专注于自己的职责，Presenter可以根据需要选择注入哪个Interactor（或者同时注入两个来完成更复杂的业务流程），这才是MVP模式中Interactor的正确用法——Interactor是封装单一业务用例的组件，而不是把所有核心业务都堆在一起的“大杂烩”。

3. 关于“核心业务规则只用一个组件”的误区 #

核心业务规则确实是项目的核心，但它可以由多个独立的、单一职责的组件协作完成，而不是必须塞进一个大组件里。模块化的设计就是把复杂的业务拆分成多个小的、可复用的模块，每个模块负责一部分，这样整个系统的可维护性和扩展性会好很多。

举个简单的例子：如果你的某个业务流程需要先从数据库取数据，再对数据做计算，那么Presenter可以先调用DataFetchInteractor获取数据，再把数据传给MathCalculationInteractor做计算，最后把结果返回给View层显示——这样每个组件的职责都很清晰，逻辑也一目了然。

内容的提问来源于stack exchange，提问作者S.Drumble1