转载自：http://www.cnblogs.com/zuoxiaolong/p/pattern1.html
设计模式（Designpattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
或者说设计模式是可以解决特定场景的问题的一系列方法。
设计模式的六大原则：
单一职责原则--每个类都只负责单一的功能，切不可太多，并且一个类应当尽量的把一个功能做到极致。
如果一个计算器类中，定义了一个add方法。其中既有取数又有计算，当你需要新增加一个减法的时候。你需要重新定义一个minus方法，取数和计算。这样取数的代码部分就会重复。可以将其拆为两个类，一个取数类，一个计算类，避免代码冗余的同时，代码也会更有有序。
里氏替换原则--一个子类应该可以替换掉父类并且可以正常工作。
慎重重写父类的方法。
接口隔离原则--即接口最小化原则，强调的是一个接口拥有的行为应该尽可能的小
比如我们设计一个手机的接口时，就要手机哪些行为是必须的，要让这个接口尽量的小，或者通俗点讲，就是里面的行为应该都是这样一种行为，就是说只要是手机，你就必须可以做到的。
public interface Mobile {
public void call();//手机可以打电话
public void sendMessage();//手机可以发短信
public void playBird();//手机可以玩愤怒的小鸟？
}上面第三个行为明显就不是一个手机应该有的，或者说不是一个手机必须有的，那么上面这个手机的接口就不是最小接口，假设我现在的非智能手机去实现这个接口，那么playBird方法就只能空着了，因为它不能玩。
所以我们更好的做法是去掉这个方法，让Mobile接口最小化，然后再建立下面这个接口去扩展现有的Mobile接口。
public interface SmartPhone extends Mobile{
public void playBird();//智能手机的接口就可以加入这个方法了
}这样两个接口就都是最小化的了，这样我们的非智能手机就去实现Mobile接口，实现打电话和发短信的功能，而智能手机就实现SmartPhone接口，实现打电话、发短信以及玩愤怒的小鸟的功能，两者都不会有多余的要实现的方法。
依赖倒置原则--高层模块不该依赖于低层模块，二者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
例：计算器取数依赖于数据读取类（只会读取文件中的数字），这样做并不是很好，因为如果我的数据不是文件里的了，而是在数据库里，这样的话，为了不影响你现有的代码，你就只能将你的Reader类整个改头换面。 或者还有一种方式就是，你再添加一个DBReader类，然后把你所有使用Reader读取的地方，全部手动替换成DBReader，这样其实也还可以接受。 那假设我有的从文件读取，有的从数据库读取，有的从XML文件读取，有的从网络中读取，有的从标准的键盘输入读取等等。你想怎么办呢？ 所以我们最好的做法就是抽象出一个抽象类或者是接口，来表述数据读取的行为，然后让上面所有的读取方式所实现的类都实现这个接口，而我们的客户端，只使用我们定义好的接口，当我们的实现变化时，我只需要设置不同的实际类型就可以了，这样对于系统的扩展性是一个大大的提升。
迪米特原则--最小知道原则，即一个类应该尽量不要知道其他类太多的东西，不要和陌生的类有太多接触。（做好类的封装）
开-闭原则--对修改关闭，对扩展开放。
书籍推荐：《大话设计模式》
随时随地看视频
