问题描述
最近我接管了一个基于MVP的android项目.简单的屏幕非常简单明了，易于阅读和维护，但应用程序中较复杂的部分却不然.多重继承级别使我在类之间切换的日子越来越长，试图找出信息流实际上是如何工作的.
Recently I took over an android project which is built on top of MVP. While simple screens are quite straight forward and easy to read and maintain, the more complex parts of the app are not. Multiple inheritance levels have caused me days of switching between classes, trying to find out how the information flow is actually working.
下面是更具问题的层次结构的一个示例:
Here one example of the more problematic hierarchies:
由于我们使用MVP，因此图中的每个类自然会有另一个Presenter类和另一个View类.
Since we use MVP, naturally there is another presenter class and another view class for each of the classes in the diagram.
所以我做了一些研究，发现了这篇文章: MVP中的组成与继承基本上是说在这种情况下，应该优先考虑使用组合而不是继承.这并不是说如何在android中应用它.我想了一会儿，但无法提出一个好的模式.我可以进行自定义视图，但是他们最终将如何使用演示者?
So I did some research and found this article: Composition vs Inheritance in MVPand it's basically saying that composition should be favoured over inheritance in this situation.What it isn't saying is how to apply that in android. I thought about it for a while, but can't come up with a nice pattern. I could do custom views, but how would they use presenters in the end?
推荐答案
继承虽然功能强大，但很容易被滥用，并且当不可避免的情况发生时，即需求发生变化时，继承很容易破坏 开放式原则 ，因为它不灵活.程序员必须修改现有的类，从而破坏客户代码.这就是为什么通常优先于继承而不是继承的原因.随着需求的变化，它提供了更大的灵活性.
Inheritance, although quite powerful, is quite easy to misuse, and when the inevitable happens, i.e change in requirements, inheritance is highly susceptible to break the open-closed principle due to its inflexibility. The programmer is bound to modify the existing classes which in turn breaks the client code.This is the reason why composition is usually favored over inheritance. It provides more flexibility with changing requirements.
此设计原则确切地说:
- 封装变化.确定代码方面的不同之处，并将其与什么保持不变.这样，我们可以在不影响其余代码的情况下对其进行更改.
- Encapsulate what varies.Identify the aspect of your code that varies and separate them fromwhat stays the same. This way we can alter them without affecting the rest of the code.
继续处理您的问题，读完您的问题后我想到的第一件事是:为什么不使用 策略模式！
Moving on to your problem, the first thing that came to my mind after I read your question was: Why not use Strategy Pattern!
您可以采用的方法是:
BaseMapViewFragment将包含所有派生类通用的所有代码.对于不同种类的行为(事物有所不同)，有单独的接口.您可以根据需要创建具体的行为类.将这些行为接口作为BaseMapViewFragment的类字段进行介绍.现在，扩展BaseMapViewFragment的类将使用具体的行为类来初始化所需的行为.
BaseMapViewFragment will contain all the code that is common to all derived classes. Have separate Interfaces for different kinds of behaviors(things that vary). You can create concrete behavior classes according to your requirements. Introduce those behavior interfaces as class fields of BaseMapViewFragment. Now classes that extend the BaseMapViewFragment will initialize the required behaviors with concrete behavior classes.
无论我在上段中所说的是什么，都可能使我感到困惑(我的英语也不太好:D)，但我只是解释了Strategy模式的工作原理，仅此而已.
Whatever I said in the above paragraph might be confusing (my english isn't that good either :D), but I just explained the working of the Strategy pattern, nothing more.
这里还有另一种设计原则:
There is another design principle at play here:
- 编程到接口，而不是实现.策略模式使用它来实现变化的代码.
- Program to an interface, not an implementation. The Strategy pattern uses it to implement the code that varies.
这篇关于如何在Android MVP中应用合成?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！