设计模式_1_6大原则

1.单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

2.开闭原则

软件实体(类、模块、函数)可以扩展,不可以修改。

3.依赖倒转原则

高层模块不应依赖底层模块。两个都应该依赖抽象、接口。
抽象不应该依赖细节，细节应该依赖抽象。
依赖接口编程，不依赖实现编程。就比如，cpu、内存条是插在主板上的接口上面，cpu、内存坏了，不用更换主板。不用品牌的主板可以适应不用品牌的cpu、内存。

4.里氏替换原则(Liskov Substitution Principle )

任何基类可以出现的地方，子类一定可以出现。
如：类“鸟”中有个方法fly，企鹅自然也继承了这个方法，可是企鹅不能飞阿，于是，我们在企鹅的类中覆盖了fly方法，告诉方法的调用者：企鹅是不会飞的。这完全符合常理。但是，这违反了LSP，企鹅是鸟的子类，可是企鹅却不能飞！需要注意的是，此处的“鸟”已经不再是生物学中的鸟了，它是软件中的一个类、一个抽象。
里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。