设计模式六大原则
开闭原则(Open Close Principle)
基本原则，其他的原则都是这条原则的扩展
这句话解释就一句 不要改以前的代码，而应该添加扩展
当然，你打算重构的话那就是另外一回事了
单一职责原则(Single Responsibility Principle)
每个类都应该实现单一的职责。简而言之，就是不能什么功能都添加到同一个类中
举一个例子:
class Animal {
void say(); //能叫
void fly(); //能飞
void sleep();
void swim();
void beCookie();//被制作成调料
void addCong();//加一点葱
void addSalt();//放点盐
...
}
显然上文的Animal类功能有点多，基本上想到什么就往里面加，一些功能完全可以拆分出来，例如加一点葱，放点盐可以单独成立一个类
里氏替换原则(Liskov Substitution Principle)
任何父类出现的地方，子类一定可以出现，而且替换成子类不会出现错误，使用者不需要知道是父类还是子类。但反过来，子类出现的地方，父类不一定可以使用
- 如果子类完全无法实现父类方法，建议断开父子类关系
- 覆盖父类方法时，子类输入参数可以放大。例如父类方法
func a(HashMap map), 那么子类方法可以是func a(Map map) - 覆盖或者实现父类方法，返回结果可以缩小。例如父类方法
List get(),那么子类方法可以是ArrayList get()
依赖倒转原则(Dependence Inversion Principle)
简而言之就是依赖接口编程，依赖抽象而不是具体实现。使用类交换时，不使用具体类，而是上层接口。例如，
HashMap map = new HashMap(), 这样写是没有问题的，但更好的写法应是Map map = new HashMap();
接口隔离原则
字面意思是每个接口不存在子类用不到的却必须实现的方法， 否则，就应该把接口拆分成多个接口。
迪米特法则(Demeter Principle)
最少知识原则, 简而言之，就是一个类对自己的依赖知道的越少越好。举个例子
- 某个public类，内部的方法除非需要提供给外部接口，不然就不要方法都使用public
- 对于提供的输入参数，返回结果， 不要出现陌生类
class A {
public void say(B b) {
print(b.c.name) //这个方法很不好，只用到了C类变量，而传入参数是B
}
}
class B {
private C c;
...
}
class C {
private String name;
}
合成/聚合复用原则
简而言之，尽量通过合成的方式组成新类，而不是直接使用继承
我需要用到HashMap的功能，那么可以这样设计
class A extends HashMap {
}
不过总觉得很怪异，这样设计更好一些
class B {
private Map map = new HashMap();
}
