设计模式遵循原则
在具体的设计模式之前需要说一说设计模式遵循的几个原则
1.开闭原则 Open Close Principle
修改关闭：扩展系统行为时不允许修改现有模块的源码
扩展开发：系统允许扩展，可以使新的行为加入系统中
该原则基础在于抽象，把系统中的行为，流程尽可能的抽象。该抽象提供可所有实现必须提供的方法特征。在设计初期我们要尽可能的预见需要扩展的功能提前抽象出来。将来系统需要扩展时可以复用抽象同时我们的抽象也不需要发生任何变化。一个抽象可以有多个实现那么我们可以根据这个特性实现扩展。由于抽象没有发生任何变化那么系统原有的组件是稳定的
2.里氏替换原则 Liskov Substitution Principle LSP
任何基类可以出现的地方子类都可以出现，该原则是继承复用的基石，开闭原则核心是抽象，所以该原则是开闭原则的补充。基类和子类就是一个抽象和具体的关系。子类可以替换父类，功能单位不会受到影响，基类才可以被复用。子类可以改写父类的行为实现对行为的扩展，也可以实现自己特有的行为.子类中特有的行为具有可见性的问题。父类是没有办法看见子类自己定义的行为的
3.依赖倒转原则 Dependence Inversion Principle
任何时候都要依赖于抽象，不是依赖于具体。该原则的含义如下
1.高层次的模块依赖于底层模块的抽象，不是依赖于底层模块的具体实现
2.具体依赖抽象
两层含义都是依赖于抽象，抽象就像规定一样他不属于抽象定义层也不属于抽象使用层，他约束了双方必须遵守的规则。只要提供的抽象不变不管使用方还是实现方如何变化彼此的影响都会很小甚至没有，因为双方都是基于抽象实现。整个过程中我们的抽象没有发生任何变化
4.接口隔离原则 Interface Segregation Principle
1.客户端的依赖应该建立在最小的接口上，由此可见使用多个接口比使用一个接口要好
2.一个接口代表一个角色，不因该将不同的角色混合在一起，客户端不应该依赖他们不需要的接口
3.不应该强迫客户端依赖或者实现它们不需要依赖或者实现的方法，如果这些方法发生改变那么客户端也需要改变
4.接口不属于任何一方，接口属于接口定义端以及客户端，是彼此需要遵守的约定
eg:订单系统
1.普通用户只允许查询
2.第三方用户只允许添加订单
3.管理员允许CRUD
public interface GeneralUser {
public Order searchOrder();
}
public interface ThridUser {
public Order createOrder();
}
public interface Admin extends GeneralUser, ThridUser{
public Order updateOrder();
public int deleteOrder();
}
public class Order implements Admin {
//避免用户直接创建对象后,访问不该访问的方法
private Order() {
}
public static GeneralUser getGeneralUser() {
return (GeneralUser)new Order();
}
public static ThridUser getThridUser() {
return (ThridUser) new Order();
}
public static Admin getAdmin() {
return (Admin) new Order();
}
@Override
public Order searchOrder() {
System.out.println("search Order");
return null;
}
@Override
public Order createOrder() {
System.out.println("create Order");
return null;
}
@Override
public Order updateOrder() {
System.out.println("update Order");
return null;
}
@Override
public int deleteOrder() {
System.out.println("delete Order");
return 0;
}
}
5.迪米特法则（最少知道原则）（Demeter Principle）
1.软件单位与单位之间尽可能少的产生依赖，需要做到高内聚低耦合
2.可以采用友元的方式使彼此之间产生依赖，此时会引入一个弊端：系统中存在大量的友元类，这些友元类起到了参数的传递，但是和具体的业务逻辑没有关系，导致系统复杂
3.成员变量,参数,返回值以及当前对象所创建的其他对象都属于当前类的友元类.友元类具有可传递性
4.可以采用访问权限的方式来实现该原则
6.合成复用原则 Composite Reuse Principle
1.尽量使用合成/聚合.避免继承.在新类中应该尽量使用关联关系采用现有的对象,使之成为新对象的一部分.达到现有功能复用的目的.
2.通过合成聚合的原则可以降低类于类之间的依赖关系.被依赖的类的修改对其他类的影响相对小一些.
3.合成/聚合原则是动态的.可以自由选择使用现有类的那些方法.而继承是静态的,失去了灵活性.如果父类改变有可能会影响子类的修改,同时破坏了父类的封装性,父类将会暴露不相关的方法给子类.
7.单一职责原则 Single responsibility principle
又叫单一功能原则,通俗的讲就是一个类或者一个方法只存在一个引起他改变的因子.应该只有一个职责.每一个职责的变化都是一个轴线.如果一个类或者一个方法存在多个引起他改变的因子.那么必然后承担过多的职责.这样就会产生耦合.那么这样的设计是脆弱的.后续也不好维护(存在多个可变因子),当一个因子发生变化时可能会影响其他职责.因为其他职责有可能依赖该因子.多个职责的耦合也会影响复用.
单一职责备受争议，在设计时候应该优先考虑接口的单一职责（粗粒度），当接口确定后集体实现时候我们需要考虑方法的单一职责。
总结:
在设计的时候应该尽量抽象,从java的角度来看我们考虑的顺序是：接口,抽象类,具体实现.同时遵循高内聚低耦合的原则,