设计模式——工厂方法模式、抽象工厂模式

最近挤了挤时间出来看了下设计模式，汗！总算来总结点东东了，最近项目忙得晕头转向了啊T.T好了言归正传，开始总结。

理论定义来一套：设计模式(Design Patterns)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码，让代码更容易被他人理解、保证代码可靠性。

设计模式的分类

设计模式主要分为三大类(主要是这二十三种)：

创建型模式：创建对象时，不再由我们直接实例化对象；而是根据特定场景，由程序来确定创建对象的方式，从而保证更大的性能、更好的架构优势。

共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式

结构型模式：用于帮助将多个对象组织成更大的结构。

共七种：适配器模式adapter、装饰器模式decorator、代理模式proxy、外观模式、桥接模式bridge、组合模式component、享元模式flyweight。

行为型模式：用于帮助系统间各对象的通信，以及如何控制复杂系统中流程。

共十一种：策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式command、备忘录模式、状态模式、访问者模式、终结者模式、解释器模式。

常用的设计模式介绍——工厂方法模式

小明很喜欢喝饮料，可是他不想总是跑去便利店买，费时又费钱，于是他从网上买了一台多功能饮料机，只要机器内部有相应的材料小明就可以制造出饮料来。这时候这台多功能饮料机就是一个工厂。好了，老规矩上代码

/**
 * 定义共同的接口
 * @author Hacfqx
 *
 */
public interface Maker {
	//多功能饮料机的制作功能
	public void make();
}

/**
 * 这是制造雪碧的按钮
 * @author Hacfqx
 *
 */
public class SpriteMaker implements Maker{
	@Override
	public void make() {
		System.out.println("雪碧出来了。");
	}
}

/**
 * 这是雪碧的按钮
 * @author Hacfqx
 *
 */
public class ColaMaker implements Maker{
	@Override
	public void make() {
		System.out.println("可乐出来了。");
	}
}

/**
 * 这是多功能饮料机
 * @author Hacfqx
 *
 */
public class MakerFactory {
	public Maker make(String type){
		if ("Cola".equals(type)) {
			return new ColaMaker();
		}else if ("Sprite".equals(type)) {
			return new SpriteMaker();
		}
		return null;
	}
}

多功能饮料机搞定了，小明想喝饮料了，那就来吧

public class FactoryTest {
	public static void main(String[] args) {
		//首先你要准备好饮料机
		MakerFactory makerFactory = new MakerFactory();
		//你想喝什么，直接点
		Maker maker = makerFactory.make("Sprite");
		//饮料制作中
		maker.make();
	}
}

结果肯定是得到了一杯雪碧了，是不是很简单！

常用的设计模式介绍——抽象工厂模式

时间久了之后，小明发现这款功能机已经满足不了，于是他打电话给厂家说，这款功能机能不能加点其他饮料的功能。

厂家想了很久答应了，为了防止以后小明提出各种各样的增加饮料功能，于是乎就有了下面的改造。这种改造不会破坏以前的饮料机制造饮料的功能，仅仅相当于你想要芬达，我给你加一个芬达的容器在机器上。你想要可乐，我给你加上可乐的容器。

/**
 * 厂家提供一些服务
 * @author Hacfqx
 *
 */
public interface Provider {
	public Maker produce();
}

/**
 * 厂家提供服务，我给你加一个芬达容器
 * 用于制造芬达
 * @author Hacfqx
 *
 */
public class FendaMakerFactory implements Provider{
	@Override
	public Maker produce() {
		return new FendaMaker();
	}
}

**
 * 厂家提供服务，我给你加一个可乐容器
 * 用于制造可乐
 * @author Hacfqx
 *
 */
public class ColaMakerFactory implements Provider{
	@Override
	public Maker produce() {
		return new ColaMaker();
	}
}

/**
 * 这是芬达按钮
 * @author Hacfqx
 *
 */
public class FendaMaker implements Maker{
	@Override
	public void make() {
		System.out.println("芬达出来了。");
	}
}

其他没有多大的改变

/**
 * 定义共同的接口
 * @author Hacfqx
 *
 */
public interface Maker {
	//多功能饮料机的制作功能
	public void make();
}

这时候就试一下吧

public class MakerTest {
	public static void main(String[] args) {
		//我有能制造芬达的饮料机，我就准备好机器
		Provider fendaProvider = new FendaMakerFactory();
		
		//我有能制造可乐的饮料机，我就准备好机器
		Provider colaProvider = new ColaMakerFactory();

		//我想喝芬达
		Maker fendaMaker = fendaProvider.produce();
		//我想喝可乐
		Maker colaMaker = colaProvider.produce();
		//按下芬达按钮
		fendaMaker.make();
		//按下可乐按钮
		colaMaker.make();
	}
}

好了，抽象工厂理解起来还是比较容易，在不破坏基本功能下(不然违背了闭包原则)，这里的意思是扩展了芬达容器，不能对可乐雪碧的制造有影响，将他们看做在同一个工厂内的单独个体，互不影响，可能这是一个糟糕的比喻！那就换句话说，抽象工厂模式在这里的好处就是，作为工厂方，为了顾客提出的各种各样的增加饮料种类的功能要求，如果你要芬达，作为厂商的我早就知道了你的需求，我只要做一个实现类，实现Maker接口,作为按钮,同时做一个芬达容器FendaMakerFactory连接着这个fendaMaker按钮...上面已经这样总结过了，我没有找到比这更能自我理解抽象工厂的比喻了-  -。