Android框架模式-MVP
一. 前言1. 介绍MVP全名是Model－View－Presenter，MVP 是从经典的模式MVC演变而来的。
Model：模型层，负责处理数据的加载或存储。与MVP中的M一样。
View：视图层，负责界面数据的展示，与用户进行交互。与MVP中的V一样。
Presenter：负责逻辑业务的处理。跟MVC中的C有所区别。
2. 作用
将Model与View彻底分离。
解决MVC中Activity职责过多，代码臃肿的问题。
3. 流程
View接受用户的请求，然后将请求传递给Presenter。
Presenter进行业务逻辑处理，修改Model。
Presenter通知View去更新界面显示。
二. MVP实例还是以点击按钮对数字+1为例子，将其改造成MVP模式。与MVC不同的是，一般Activty会当作View层来处理。
1. Model层处理跟MVC不同的地方在于Model不会跟View发生交互，只会跟Presenter交互。
123456789101112131415public class NumModel { private int num = 0 ...
Android框架模式-MVC
一. 前言1. 介绍MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，是一种框架模式。
Model：模型层，负责处理数据的加载或存储。
View：视图层，负责界面数据的展示，与用户进行交互。
Controller：控制器层，负责逻辑业务的处理。
2. 作用将业务逻辑、数据、界面分离的一种代码组织方式，修改界面时无需去修改业务逻辑。
3. 流程
View接受用户的请求，然后将请求传递给Controller。
Controller进行业务逻辑处理后，通知Model去更新。
Model数据更新后，通知View去更新界面显示。
二. MVC实例Android中一般布局的XML文件就是View层，Activity则充当了Controller的角色。
根据我们的需要编写模型类。
1. Model层创建一个数据模型，能够保存一个数字，并有一个更新的方法，数据更新完后会通知UI去更改显示的内容。
123456789public class NumModel { private int num = ...
Android设计模式-概述
一. 前言1. 定义
某类特定问题的代码设计解决方案
是一套代码设计的经验总结
设计模式，其实只是前人针对某类问题的代码设计经验而已，并没有很高大上 (md info supported)
2. 作用
提高代码复用率，降低开发成本和周期
提高代码可维护性、可拓展性
使代码更加优雅
让代码更容易被他人理解
二. 设计模式的设计原则
1. 单一职责原则一个类=只有一个引起它变化的原因。
如果一个类承担的职责过多，即耦合性太高=一个职责的变化可能会影响到其他的职责。
2. 开放封闭原则一个实体（类、函数、模块等）应该对外扩展开放，对内修改关闭。
即每次发生变化时，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。
符合开放封闭原则的最好方式是提供一个固有的接口，然后让所有可能发生变化的类实现该接口，让固定的接口与相关对象进行交互。
3. 里式代替原则子类必须替换掉它们的父类型。
在软件开发过程中，子类替换父类后，程序的行为是一样的。
只有当子类替换掉父类后软件的功能不受影响时，父类才能真正地被复用，而子类也可以在父类的基础上添加新的行为。
4. 依赖 ...
Android设计模式-适配器模式
一. 前言1. 定义Adapter Pattern：定义一个包装类，用于包装不兼容接口的对象。
包装类 = 适配器Adapter。
被包装对象 = 适配者Adaptee = 被适配的类。
作用：
把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法一起工作的两个类能够在一起工作。
二. 类的适配器模式1. 概述冲突：Target期待调用Request方法，而Adaptee并没有（这就是所谓的不兼容了）。
解决方案：为使Target能够使用Adaptee类里的SpecificRequest方法，故提供一个中间环节Adapter类（继承Adaptee & 实现Target接口），把Adaptee的API与Target的API衔接起来（适配）。
2. 代码123456789101112131415161718192021222324252627282930313233343536public class ClassAdapter { /** * 目标接口：Target */ public interface Target ...
Android设计模式-建造者模式
一. 前言1. 定义Builder Patter：隐藏创建对象的建造过程 & 细节，使得用户在不知对象的建造过程 & 细节的情况下，就可直接创建复杂的对象。降低了创建复杂对象的复杂度，离了创建对象的构建过程。
二. 代码实战1. 概况背景：小成希望去电脑城买一台组装的台式主机。
过程：
电脑城老板（Diretor）和小成（Client）进行需求沟通。（买来打游戏？学习？看片？）
了解需求后，电脑城老板将小成需要的主机划分为各个部件（Builder）的建造请求。（CPU、Memory、HD）
指挥装机人员（ConcreteBuilder）去构建组件。
将组件组装起来成小成需要的电脑（Computer）。
2. 代码123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949 ...
Android设计模式-工厂模式
一. 前言1. 定义SimpleFactoryPattern：简单工厂模式又叫做静态工厂方法模式（因为工厂类定义了一个静态方法），定义一个用于创建对象的接口，让子类决定实例化哪个类。
Factory Method：工厂方法模式，又称工厂模式、多态工厂模式和虚拟构造器模式，通过定义工厂父类负责定义创建对象的公共接口，而子类则负责生成具体的对象。将类的实例化（具体产品的创建）延迟到工厂类的子类（具体工厂）中完成，即由子类来决定应该实例化（创建）哪一个类。
Abstract Factory：抽象工厂模式，即Abstract Factory Pattern，提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类；具体的工厂负责实现具体的产品实例。抽象工厂模式与工厂方法模式最大的区别：抽象工厂中每个工厂可以创建多种类的产品；而工厂方法每个工厂只能创建一类。允许使用抽象的接口来创建一组相关产品，而不需要知道或关心实际生产出的具体产品是什么，这样就可以从具体产品中被解耦。
二. 简单工厂模式1. 概况背景：一个工厂生产多种产品。
2. 代码123456789101112131415161 ...
Android设计模式-代理模式
一. 前言1. 定义Proxy Pattern：给目标对象提供一个代理对象，并由代理对象控制对目标对象的访问。
二. 静态代理1. 概况背景：有一个人想找代购，购买口红。
2. 代码123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960/** * 静态代理 */public class StaticProxy { /** * 抽象的需求类 */ public interface Person { //买东西 void buy(); } /** * 真实的需求类 */ public static class Demand implements Person { String thing; public Demand(String thing) { ...
Android设计模式-单例模式
一. 前言1. 定义Singleton：确保某个类只有一个实例,并且自行实例化并向整个系统提供这个实例。
二. 实现方式1. 饿汉式12345678910public class Singleton { //1.私有化构造方法 private Singleton(){} //2.实例化对象，并提供获取方法 private static final Singleton instance = new Singleton(); public static Singleton getInstance(){ return instance; }}
优点：写法简单，线程安全。
缺点：如果没有使用过的话会造成内存浪费，没有懒加载的效果。
2. 懒汉式12345678910111213141516public class Sinleton { //1.私有化构造方法 private Singleton(){} //2.声明对象 ...
