所有的设计模式的出现都是为了解决某一特定的问题，所以在选择设计模式的时候千万要注意使用场景，在编程中没有万金油一样的设计模式，因此没有最好的设计模式，只有最适合的设计模式。
例如Android中经常被提到的几种设计模式 MVC、MVP、MVVM，实际上都是在特定的情景下产生的模式。
MVC 产生于UI出现之后，在UI出现之后为了协调UI和业务之间的逻辑就出现了MVC模式，它将数据划分为M，UI划分为V，其中M和V基本都可以独立，相对来说复用性也更好，但是用于协调两者关系的C则很尴尬了，因为C从一开始就是为了特定的场景而生的，一旦脱离了这个场景，这个C也就没用了，所以C的可复用性最差。然而，C作为了M和V之间的协调者，所承担的担子是非常重的，它既能直接操作M，也能直接和V交互，所以随着业务的壮大C就变得越来越沉重。
为了解决C变得越来越沉重的问题，于是产生了MVP模式，该模式本质上只干了一件事情，那就是让本来的C只干自己应该干的事情，而不要去承担过多的责任，原本M该干的事情就交给M，原本V该干的事情就交给V，自己只当一个管理协调者，于是换了一个名字叫P，这便是MVP的产生。
由于平台原因，MVP在Android上使用起来很麻烦，为了将M、V、P之间的业务隔绝起来，它们之间使用接口进行交互，尽管这样从理论上可以更好的解耦，但在实际操作过程中却会发现这就像是脱裤子放屁，例如：P和V之间本身就是需要交互的，并且在大部分场景下，一个P只会对应一个V，也就是两个文件，但是使用了接口之后会平白变成四个文件(多了两个接口文件)，然而到了实际业务改动的时候，从改动两个地方，变成了改动四个地方，需要先改接口，再改实现，最后改调用者，所以强行套用MVP模式不仅不会更方便，反而变的麻烦。
后来又有人提出了MVVM模式，这个模式和MVP有的类似，但是原理更加先进了一点，它将VM和V之间的双向联系变成了单向联系。