风居住的城市

简单工厂模式将对象的实例方法了工厂中创造，程序比较简单，只是将原本应该出现在客户程序的判断放到了工厂中，参照《Head First》的例子，有一个PizzaStore卖各种口味的Pizza。//PizzaStore 它的orderPizza只返回一个抽象的Pizza，而具体的实例交有工厂去处理package Factory.SimpleFactory;/** * Created by

简单工厂将字符串判断交给了工厂工厂方法模式不同的工厂创建了不同的产品接着Pizza的例子，假设createPizza()只是得到了Pizza,交给客户之前这个pizza还需要做一些其他的工序，如撒点肉松、包装等（这里将这些操作统一叫做prepare()）。而这些prepare在纽约店和在芝加哥店都是不一样的。那怎么办？抽象工厂代码如下：首先是Pizza超类，可以看到拥有一个保护的 Pi

核心思想：定义算法族，让族内算法可以相互替换，使得算法独立于使用的客户。例程参照了《Head First》，建立一个鸭子的类群假设这群鸭子中：有些鸭子会飞有些不会，有些鸭子会叫有些则不会，但是所有鸭子都会游泳。最初会想到让所有鸭子继承一个抽象的超级鸭类。如下：可以看到这样所有的鸭子都会游泳都会叫都会飞，这显然不能满足要求（因为有些鸭子不会飞，有些鸭子不会叫），当然，可以在特殊的

这个模式从字面上就很好理解了：肯定有一个观察的对象，然后有一群观察者。观察者模式我觉得更像是一种通知模式，当对象发生变化是，通知所有的观察者。依然参用《Head First》的例子：有一个气象站，测量温度（Temperature），湿度（Humidity），气压（Pressure)三个参数，有三个显示设备（观察者）。首先可以分析一下：1，肯定需要一个可供观察的对象WeatherDa

核心：只持有抽象的接口引用，由子类去决定实例的创建，将实例化推到子类中去。同样采用Pizza的例子，当纽约（NY）和芝加哥（Chicago）都开了pizza店，且者两个地方的同类型Pizza味道不同。可以构建如下类：可以看到createPizza在父类中申明为抽象的，用户首先得创建一个店,NYPizzaStore store，当用户调用AbstractPizzaStore.orde

有时候必须向某个对象提交请求，但是却并不知道关于被请求操作或请求的接收者的任何信息。命令模式的关键是一个抽象的Command类或接口。这个Command抽象类（或接口）里面包含了一个执行命令的方法execute()。这个方法由具体Command去实现。假设有一个遥控器，它有四个按钮，需要将其中的两个设计为灯（Light）的开、关，另外两个控制收音机（Video）的开、关。在这个例子中遥

我们知道，一般类的构造方法都应该申明为public，这样这个类才能被创建实例。这样的类在外部可以创建多个实例。如果想避免类被重复实例化，就需要强制手段了。显然，把这个类声明为静态的就可以了，但这样做这个类存在于整个程序的生命周期，并不好。我们真正需要的是，像普通类那样在用到的时候才被实例化。可以想到将类的构造函数声明为私有的，然后以一个类内的静态函数去调用这个构造函数并返回实例。如下pac

适配器模式可以将一个类的接口转换成客户希望的另一个接口。当然，前提是这个类有能力实现客户希望的那些功能，否则转换毫无意义。现假设有一个Duck接口，它只要两个方法，定义如下：package Adaptor;/** * Created by sgzhang on 2015/8/17. */public interface Duck { void quack(); v

装饰者模式可以动态的给一个对象添加一些额外的职责。假设你去饮料店，要了一杯加Milk和Soy的espresso。想象一下柜台是怎样给你打印发票和计算价钱的呢？饮料店可是有很多主饮和配料的，基本可以随意加配料。显然不可能为每一种组合都建立一个类。那怎么办？先从主函数开始分析：package Decorator;/** * Created by sgzhang on 2015/8/17.