我有几个活动，虽然每个活动都很独特，但必须有一些常见的api调用，如getCurrentUser（）或updateUser（）
鉴于MVP模式（我目前正在使用MVP mosby），因为每个活动只有一个演示者。正如我正在开发的那样，有时我会在这些演示者身上复制粘贴很多这些常见的api调用。假设我有api呼叫A，B，C，D。
A，C用于演示者1，
B，D，A用于演示者2，
C，E用于演示者3 .....
等等。很难找到一个继承的“共同”主持人。所以api调用，C和A基本上都是复制粘贴的。
我的问题是，鉴于目前的情况，避免代码复制粘贴的最佳方法是什么？这几乎是不可避免的吗？或者，我是否应该尽力做OOP，但每次从不同的演示者添加/删除API调用时都要冒一堆重构？
答案 0 :(得分：3)
交互式模式（用例模式）可以解决当前重复代码的问题。
我们的想法是将getCurrentUser()和updateUser()方法后面的所有逻辑提取到类（交互器）中，并在多个演示者中使用此交互器。
答案 1 :(得分：2)
您应该通过将所有API调用放在一个或多个可以从任何演示者引用的Java类中来解耦您的公共API和演示者代码。
因此。 ServiceA存在（Java类）。
ServiceA执行API调用A，B，C，D。
可以从Presenter1，Presenter2，PresenterN，PresenterN + 1调用服务A. 演讲者是什么并不重要。
如果要限制某些演示者可以访问不同的API调用。那么这就是你应该考虑使用ServiceA，ServiceB，ServiceC的时候。在ServiceA只能进行API调用A和D的情况下，服务B和服务C的行为类似。
将Presenter代码与常用代码（Web服务，内部API，w / e代码）分离，您无需进行复制和粘贴即可进行扩展。
祝你好运。答案 2 :(得分：0)
如果你不做OOP风格的继承，我认为你冒着更多的重构风险。 我们假设您要修改处理api调用的方式。如果要复制代码，则必须首先在重复代码的任何地方重构代码。如果从公共演示者继承，则只需修改一次。
答案 3 :(得分：0)
您应该为包含所有API请求的API创建界面。然后创建执行这些请求的单例类，您可以从演示者轻松访问此类。
现在你仍然会有一些重复，你需要在演示者中多次调用这个单例，并在每个单元中处理响应，但这就是你需要做的事情。每个演示者都应该能够以不同的方式处理响应，因此您不能将它们打包为一个（即使他们通常也会以相同的方式处理它 - 通过将数据传递给视图）。
如果您认为自己编写了大量类似的代码而无法执行任何操作，那么您可以使用MVP获得的代码。您还可以获得出色的测试能力，更容易的重构以及轻松模拟请求 - 您可以将实际的单例交换为实现相同界面的模拟，并且一切正常。