设计模式VS框架
框架是代码的重用，可扩展。举几个简单的例子。Spring架构，Struts架构。
设计模式是设计的重用，是一种抽象的设计方法。例如MVC，MVP，MVVM。
下面，我们以android开发为例，简单比较一下三种不同的设计模式。
MVC
MVC是指Modle，View和Controller，将界面，业务逻辑和控制器分开，是一种低耦合的设计方式，适用于简单应用开发。
举个简单的例子。android中的各种控件，即为View。例如，一个Button。如果这个Button用于获取服务器信息，我们可以将具体功能实现封装成一个功能类，叫做HttpUtil。并将获取的服务器信息，存放在ServerResponse类中。那么，HttpUtil和ServerResponse即为Modle。那么谁是Controller呢？Activity即为Controller，它将Modle和View连接起来。点击Button，将触发Activity的onClickLisener方法，从而进一步触发HttpUtil类。HttpUtil在获取结果后，将其封装为ServerResponse，ServerResponse显示至相应控件。
这种设计模式最为简单，但问题有三。
（1）View与Modle（ServerResponse类）相互可见，耦合度高。
（2）如果程序复杂，那么Activity这个Controller将十分繁琐复杂，不容易维护。
（3）Activity角色模糊，View或Modle。
因此，从MVC的基础上，衍生出了MVP模式。
MVP
P是指Presenter，即实现者，功能与Controller类似。Presenter实质为Interface类的运用，用于降低M，V，C间的耦合度，主旨是为Activity或Fragemnt瘦身。
Activity或Fragment瘦身后，应只包含setListener，生命周期控制，View接口实现，init以及Presenter的调用。而具体的操作，都在Presenter Implimentation类中实现。
经典的MVP模式，基本上包括6个部分
（1）View接口
View接口，用于定义View的更新逻辑，这个接口需要在Acitivity中实现。比如，显示进度条，隐藏进度条，控件text更新等。
（2）View接口实现类
即原有的Activity和Fragment。该类中将进行Presenter接口实现类的初始化，以及Presenter相应接口的调用。
（3）Presenter接口
Presenter接口，用于定义业务逻辑。例如请求网络数据。
（4）Presenter接口实现类
用于实现Presenter定义的具体业务。此类将View接口和Modle接口作为自身的成员变量。前者由View接口实现类，在对Presenter接口实现类进行初始化时传入。而Modle接口变量，在Presenter接口实现类中进行初始化。
（5）Modle接口
Modle接口，用于定义Modle共有特性。该接口可有可无。
（6）Modle接口实现类
Modle接口的具体实现，可以理解为上例中的ServiceResponse对象。
由此可见，Presenter接口实现类是整个模式的核心部分，Modle和View在此通过接口的形式进行交互。
MVP模式，容易维护，可拆卸，可扩展，耦合性较MVC小，结构清晰。
MVP的缺点，在于开发开销相对较大。与MVC相比，需要维护更多的接口。
MVVM
MVVM由三部分组成，M，V，VM，分别代表Modle，View，ViewModle。谈论MVVM模式的前提，需要了解DataBinding，即将Modle与View进行绑定，包括单向绑定（Modle影响View），双向绑定（Modle与View相互影响）。
而DataBinding的实现，需要在View中引入Modle（布局文件中加入data节点，加入数据类的引用），同样Modle中也要实现对View中控件的绑定（双向绑定时）。而这样的后果是，不仅没有将两者隔离，反而增加了耦合度。这与个人的编程习惯相抵触，因而较少使用。
MVVM模式的侧重点，在于数据和UI的联动，自动更新，而非降低耦合度。对于耦合度的问题，其实还需要结合MVP模式来解决。