设计模式几大基本原则

一、单一职责原则

不应该让一个类承担过多的职责。如果某一个类有多个职责，应该考虑职责分离。

比如定义一个摄像机的产品对象，很明显最好只让它有一个  摄像的职责，而不是应该让它还能发微信，记账等等。摄像机的单一职责就是摄像，加入其它东西就不合理。

张三好好开拖拉机耕地，不要用拖拉机载客 。载客是小轿车的事！

二、开放封闭原则

对于扩展开放，对于修改封闭。对程序的改动是通过新增代码实现的，而不是更改现有的代码。

三、里氏替换原则

子类必须能够替换掉他们的父类型。

四、依赖倒转原则

高层模块不应该依赖底层模块，两个都应该依赖抽象。

抽象不应该依赖细节，细节应该依赖抽象。

面向接口编程，不要面向实现编程。（这句话本身就有点抽象。）

比如定义一个Car 接口，接口这个范畴就属于“抽象”。实现有Bus公共汽车，truck卡车，ambulance救护车

定义一个Driver类，司机驾驶员。

每个车都有行驶的功能，我们定义的时候就这么来：

class Driver{
　　 public void busDriver(Bus bus){
        bus.run();
    }

    public void truckDriver(Truck truck){
        truck.run();
    }

    public void ambulanceDriver(Ambulanceam bulance){
        ambulance.run();
    }

}

在调用的时候就需要分别调用各个实现的busRun  truckRun  ambulanceRun，这就是对于实现类的编程，而没有做到针对接口编程。

对于接口编程，我们应该遵循接口规范，比如在Car接口中定义一个抽象方法run()，然后所有的子类都实现这个run方法。

调用者，比如驾驶员张三去驾驶的时候，使用Car car = new Bus();  直接传入参数到carDriver(Car car)去调用car.run()就好了。

什么？ 你说你又改造了一辆新车，你就说这个新车是不是车吧？那必须是啊，是的话就挂挡踩油门car.run()，就不管你是大货车.油门  还是救护车.油门。踩油门就完事了，等你再来车也是一样。

class Driver{
　　 public void carDriver(Car car){
        car.run();
    }

}

 五、迪米特法则

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

其前提是：在类的结构设计上，每个类都应当尽量降低成员变量的访问权限。强调类之间的松耦合。