Question

通常使用Java，我们会创建一个*Contract接口来处理 View 和 Presenter 之间的交互，例如：

MainActivity
为View

public class MainActivity extends Activity implements MainContract {

@Override
public void onCreate(Bundle b) {
   presenter.requestData();
}

@Override
public void showData(String data) {
   // Handle data ...
}

MainPresenter
为Presenter

public class MainPresenter {

   public void requestData() {
      contract.showData("data");
   }
}

MainContract
为interface

public interface MainContract {
   void showData(String data);
}

既然Kotlin具有“高阶功能” 功能，应该，我们只是传递函数来处理视图和演示者之间的交互？可能是这样的：

查看：

presenter.requestData { data ->
   // Handle data
}

演示者：

fun requestData(handler: (String) -> Unit) {
   handler("data")
}

我不是在问这种可能性，而是在问这是否是最佳实践。

Answer 1

这个问题的答案更多是与体系结构决策相关，而不是技术限制。您可以在Java（甚至在Java7中）中使用匿名实例来实现相同的事情（当然，这样做会有更多样板，并且更难阅读）。

在MVP中，具有由视图实现的合同的想法是，每个演示者都知道如何获取，操纵和呈现给该合同。一个视图可能实现多个合同并具有多个演示者。同样，每个演示者实例仅适用于合同的一个实现，但是您可以有两个实例为两个不同的实现提供服务。

如果不是每个视图都符合每个演示者的合同，那么每个演示者的呼叫迟早都会花费lambda，您最终会遇到问题。

例如，假设一个演示者异步获取数据并将其缓存在内存中：

该视图调用presenter方法fetchData()。
演示者调用合同的showLoading()方法。
（有些时候过去了）
演示者调用合同的hideLoading()和showData(data)方法。
用户进行交互并再次触发fetchData()
演示者使用缓存的数据调用showData()

在这种情况下，如果我们使用lambda而不是合约，则需要以相同的方法请求两个不同的lambda：一个用于缓存时间，另一个用于不缓存时间。我们还将视图实现与演示者耦合在一起，将来演示者接口的另一种实现可能不需要这两个lambda，因为逻辑已更改。

重要的是要记住，在MVP中，理想情况下，视图和演示者都可以通过接口相互通信，在这种情况下，演示者接口不应受实现细节的影响，而应公开其能够执行的操作。

在MVP中使用Kotlin高阶函数

1 个答案: