继上一篇 Android经常使用设计模式（一）里认识了观察者。适配器。代理等三种模式，这一篇将会解说下面三种模式：
- 工厂模式
- 单例模式
- 命令模式
1.工厂模式(Factory Pattern)
工厂模式分为简单工厂模式。工厂方法模式以及抽象工厂模式
- 简单工厂模式：普通情况下，提供一个方法，方法的參数是一个标志位。依据标志位来创建不同的对象。这样调用的时候仅仅须要提供一个标志位就能够创建一个实现了接口的类。
- 工厂方法模式：将简单工厂模式的那个方法分开。不再是在工厂方法中依据标志位创建对象了。而是定义一个工厂接口。然后想创建几个不同类型的对象（即实现了同一接口的不同java类），就创建了几个不同类型的工厂。也就是创建的对象和创建对象的工厂是一一相应的。然后client调用的时候直接去实例化一个详细的对象工厂。创建相相应的对象。
- 抽象工厂模式:事实上这个名起的有点不知所云没有表达出这个模式的特点。
事实上这个模式就是工厂方法模式的略微扩展一下而已。工厂方法模式里面。一般一个工厂接口仅仅有一个方法。比方createMouse()。然后用实现了这个接口的详细工厂类仅仅能生产鼠标。
而抽象工厂模式就是一个工厂接口有多个方法，比方createMouse() , createKeyboard() 。 这样实现了这个工厂接口的详细工厂类就能够既生产鼠标又生产键盘。
常见实例：比方android的bitmap中经常使用的BitmapFactory类，创建Bitmap对象，通常使用静态工厂方法
这里主要介绍简单工厂与工厂方法的差别：
就以大话模式中小菜跟大鸟举得雷锋故事作为题材吧。
LeiFeng类：
//雷锋
public interface LeiFeng {
void sweep();//扫地
void wash();//洗衣
void buyrice();//做饭
} Student类：
//学做雷锋的大学生
public class Student implements LeiFeng{
public void buyrice() {
System.out.println("大学生做饭");
}
public void sweep() {
// TODO Auto-generated method stub
System.out.println("大学生扫地");
}
public void wash() {
// TODO Auto-generated method stub
System.out.println("大学生洗衣");
}
} Valuator类志愿者：
//学做雷锋的志愿者
public class Valuator implements LeiFeng{
public void buyrice() {
System.out.println("志愿者做饭");
}
public void sweep() {
// TODO Auto-generated method stub
System.out.println("志愿者扫地");
}
public void wash() {
// TODO Auto-generated method stub
System.out.println("志愿者洗衣");
}
}然后简单工厂是这么实现的：
//使用简单工厂
public class SimpleFactory {
public static LeiFeng createLeiFeng(String type){
if("大学生".equals(type)){
return new Student();
}else if("志愿者".equals(type)){
return new Valuator();
}
return null;
}
} 而工厂方法模式中，则多了一个接口去创建不同类型的对象：
Factory类：
//工厂方法模式，工厂接口
public interface Factory {
LeiFeng createLeiFengFactory();
}StudentFactory学生工厂：
//学生工厂
public class StudentFactory implements Factory{
public LeiFeng createLeiFengFactory() {
return new Student();
}
} ValuatorFactory志愿者工厂：
//志愿者工厂
public class ValuatorFactory implements Factory{
public LeiFeng createLeiFengFactory() {
return new Valuator();
}
} 当我们实现起来时：
public static void main(String[] args) {
//简单工厂模式
LeiFeng f11=SimpleFactory.createLeiFeng("大学生");
f11.buyrice();
LeiFeng f22=SimpleFactory.createLeiFeng("大学生");
f22.wash();
//使用工厂方法模式
Factory fac=new StudentFactory();
LeiFeng f4=fac.createLeiFengFactory();
f4.buyrice();
LeiFeng f5=fac.createLeiFengFactory();
f5.wash();
}这里就要说说为什么要使用工厂方法模式，由于简单工厂使用起来明显要方便简约的多。从理论的角度来说，工厂方法模式更符合封闭-开放原则。即对改动封闭对扩展开放。
试想后期维护过程中要添加一个种类的对象，也就是添加对接口的一种实现，简单工厂模式就要在switch…case中添加一个case项，无疑是改动了工厂方法。
如果是jar包模式的，就要又一次发包了。可是工厂方法模式，全然不须要更改工厂接口。仅仅是新添加一个实现的工厂类就可以（如果是jar包模式的。就能够不用又一次发jar包，让用jar包的人自己去扩展一个实现了工厂接口的详细工厂类就可以）。全然符合封闭-扩展原则。
2.单例模式(Single Pattern)
释义：单例模式确保某一个类仅仅有一个实例，并且自行实例化并向整个系统提供这个实例单例模式。
单例模式仅仅应在有真正的“单一实例”的需求时才可使用。
故事理解：俺有6个美丽的老婆。她们的老公都是我。我就是我们家里的老公Sigleton，她们仅仅要说道“老公”，都是指的同一个人。那就是我
常见实例：数据库创建时使用单例模式。Servlet环境下共享同一个资源或者对象
适用场景：对于定义的一个类，在整个应用程序运行期间仅仅有唯一的一个实例对象。如Android中常见的Application对象。
单例模式可分为饿汉式，懒汉式等：
（一）饿汉式：其特点是应用中尚未须要用到此单一实例的时候即先实例化。
public class SingleTon {
// 静态实例变量，直接初始化
private static SingleTon instance = new SingleTon();
// 私有化构造函数
private SingleTon() {
}
// 静态public方法，向整个应用提供单例获取方式
public static SingleTon getInstance() {
return instance;
}
}(二)懒汉式：其特点是延迟载入。即当须要用到此单一实例的时候，才去初始化此单一实例。
public class SingletonA {
/**
* 单例对象实例
*/
private static SingletonA instance = null;
public static SingletonA getInstance() {
if (instance == null) { //line 12
instance = new SingletonA(); //line 13
}
return instance;
}
}
在这里要说下懒汉式。由于它具有一定的缺陷。我们能够如果这样的场景：两个线程并发调用Singleton.getInstance()。如果线程一先推断完instance是否为null，既代码中的line 12进入到line 13的位置。刚刚推断完成后，JVM将CPU资源切换给线程二。由于线程一还没运行line 13。所以instance仍然是空的，因此线程二运行了new Signleton()操作。片刻之后，线程一被又一次唤醒。它运行的仍然是new Signleton()操作。
所以对它进行了改良：
public class SingletonB {
/**
* 单例对象实例
*/
private static SingletonB instance = null;
public synchronized static SingletonB getInstance() {
if (instance == null) { //line 12
instance = new SingletonB(); //line 13
}
return instance;
}
}往方法上加了个同步锁，这样就能够保证不会出线程问题了，可是这里有个非常大（至少耗时比例上非常大）的性能问题。除了第一次调用时是运行了SingletonB的构造函数之外。以后的每一次调用都是直接返回instance对象。返回对象这个操作耗时是非常小的。绝大部分的耗时都用在synchronized修饰符的同步准备上，因此从性能上说非常不划算。
所以又进行了改进：
public class SingletonC {
/**
* 单例对象实例
*/
private static SingletonKerriganD instance = null;
public static SingletonC getInstance() {
if (instance == null) {
synchronized (SingletonC.class) {
if (instance == null) {
instance = new SingletonC();
}
}
}
return instance;
}
}
眼下我用的版本号也就是这样的。然而，网上有人又对这样的单例模式进行了改进。由于还是存在缺陷。详细能够去网上拓展下。
再说说饿汉式的写法。这样的写法不会出现并发问题，在ClassLoader载入类后实例就会第一时间被创建。
但饿汉式的创建方式在一些场景中将无法使用：譬如实例的创建是依赖參数或者配置文件的，在getInstance()之前必须调用某个方法设置參数给它。那样这样的单例写法就无法使用了。
3.命令模式（Command Pattern）
释义：把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和运行命令的责任切割开。委派给不同的对象。
命令模式同意请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收。以及操作是否运行，何时被运行以及是怎么被运行的。
故事理解：俺有一个MM家里管得特别严，没法见面，仅仅好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同一时候给我姐姐三个男朋友送COMMAND，就数你最小气。才请我吃面。
常见实例：经常使用的Runnable(在java.lang包下)，事实上就是用了命令模式。详细的体现过程，可见该博客
Runnable下的命令设计模式
适用场景：1. 命令的发送者和命令运行者有不同的生命周期。命令发送了并非马上运行。2. 命令须要进行各种管理逻辑。
3. 须要支持撤消重做操作（这样的状况的代码大家能够上网搜索下，有非常多。这里不进行详细解读）。
事实上经典的命令模式包含4个角色：
Command：定义命令的统一接口
ConcreteCommand：Command接口的实现者，用来运行详细的命令，某些情况下能够直接用来充当Receiver。
Receiver：命令的实际运行者
Invoker：命令的请求者，是命令模式中最重要的角色。
这个角色用来对各个命令进行控制。
接下来。就以小菜大鸟去烧烤店。给服务员报菜，然后服务员通知厨师为样例。
Command类 ：
/*
* 抽象命令
*/
abstract class Command {
protected Barbecuer barbecuer;
public Command(Barbecuer barbecuer) {
this.barbecuer = barbecuer;
}
// 运行命令
public abstract void excuteCommand();
} (Receiver类）Barbecuer:
/*
* 烤肉串者
*/
class Barbecuer {
// 烤羊肉串
public void bakeMutton() {
System.out.println("烤羊肉串!");
}
// 烤鸡翅
public void bakeChickenWing() {
System.out.println("烤鸡翅!");
}
} （ConcreteCommand类） BakeMuttonCommand、BakeChickenWingCommand：
/*
* 烤羊肉串命令
*/
class BakeMuttonCommand extends Command {
public BakeMuttonCommand(Barbecuer barbecuer) {
super(barbecuer);
}
@Override
public void excuteCommand() {
barbecuer.bakeMutton();
}
@Override
public String toString() {
return "命令模式，烤羊肉串命令。";
}
}
/*
* 烤鸡翅命令
*/
class BakeChickenWingCommand extends Command {
public BakeChickenWingCommand(Barbecuer barbecuer) {
super(barbecuer);
}
@Override
public void excuteCommand() {
barbecuer.bakeChickenWing();
}
@Override
public String toString() {
return "命令模式，烤鸡翅命令！ ";
}
}
(Invoker类）Waiter ：
/*
* 服务员
*/
class Waiter {
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
private List<Command> orders = new ArrayList<Command>();
// 设定订单
public void setOrder(Command command) {
orders.add(command);
System.out.println("添加订单：" + command.toString() + " 时间：" + simpleDateFormat.format(new Date()));
}
// 取消订单
public void cancelOrder(Command command) {
orders.remove(command);
System.out.println("取消订单：" + command.toString() + " 时间：" + simpleDateFormat.format(new Date()));
}
// 通知所有运行
public void notifyA() {
for (Command command : orders) {
command.excuteCommand();
}
}
} Client类实现（例如以下）：
public class CommandMode {
public static void main(String[] args) {
// 开店前准备
Barbecuer boy = new Barbecuer();
Command bakeMuttonCommand1 = new BakeMuttonCommand(boy);
Command bakeMuttonCommand2 = new BakeMuttonCommand(boy);
Command bakeChickenWingCommand = new BakeChickenWingCommand(boy);
Waiter girl = new Waiter();
// 开门营业
girl.setOrder(bakeMuttonCommand1);
girl.setOrder(bakeMuttonCommand2);
girl.setOrder(bakeChickenWingCommand);
// 点菜完成。通知厨房
girl.notifyA();
}
} 总结来说，命令模式是将功能提升到对象来操作，以便对多个功能进行一系列的处理以及封装。
这里要建议下命令模式的使用，当我们不清楚是否须要使用时。一般不用着急去实现它。事实上，在须要的时候通过重构实现这个模式并不困难。仅仅有在真正须要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。
最后，设计模式的运用。有助于代码的维护与拓展。不论什么模式的出现。都是为了解决一些特定的场景的耦合问题，以达到对改动封闭，对扩展开放的效果。
六种模式。学习它们，提高自己！
除了这六种。还有几种比較经常使用的。接下来会继续思考。继续熟悉。