六大设计原则-里氏替换原则

    里氏替换原则，重点在于理解“替换”一词的意思。在Java程序设计中，“替换”发生在继承里面的重写过程中。这样就很明显了。所谓的里氏替换原则主要是让我们在使用继承关系时，为了避免代码混乱所要求程序员准守的一种设计原则。

    使用继承，是存在风险的。比如：1.B类继承A类，由于A类具有很多的方法，在B类中不小心重写了A类的方法。造成使用B类方法式，语义混乱。2.当父类方法修改时，影响了子类对原有功能的使用。面对这样的情况，很明显，我们对于继承关系，是能免则免得。往往在设计的过程从，把A和B类抽象出来成为一个抽象类或者接口，然后使用依赖，关联，聚合和组合灯关系代替。

    面对不得不重写的方法，在里氏替换原则中，我们要满足以下的要求：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

• 子类中可以增加自己特有的方法。

• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

                检验是否满足里氏替换原则的方法：

                如果父类方法的输出结构和子类方法的输出结构一致，则满足，不一致，则不满足。

                依赖转置原则：

                1.高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

                "依赖"在Java设计中，只有在方法参数中，才会使用到依赖。依赖就是在参数中引用到另外一个类的对象。所以依赖转置原则就是方法中参数使用类型的原则。简单的说，方法中参数使用类型应尽量使用具有概括意义的父类（接口）。

例子：

    

/**

 * 抽象类

 * @author BeiChengLuo

 *

 */

public interface Fool {

void foolName();

}

/**

 * 实现类 - 米饭

 * @author BeiChengLuo

 *

 */

public class Rice implements Fool{

@Override

public void foolName() {

// TODO Auto-generated method stub

System.out.println("饭");

}

}

/**

 * 实现类 -- 面条

 * @author BeiChengLuo

 *

 */

public class Noodle implements Fool{

@Override

public void foolName() {

// TODO Auto-generated method stub

System.out.println("面");

}

}

/**

 *高程模块 -- 人 （应该依赖于抽象）

 * @author BeiChengLuo

 *

 */

public class Person {

// 依赖接口 Fool， 实际上就是可以使用接口的所有实现类（非接口可以使用其所有子类）。

public void eat(Fool fool){

fool.foolName();

}

}

/**

 * 

 * @author BeiChengLuo

 *

 */

public class MainClass {

public static void main(String[] args) {

Fool rice = new Rice();

Fool noodle = new Noodle();

Person person = new Person();

person.eat(rice);

person.eat(noodle);

}

}

输出：

    饭

    面

    接口隔离原则：

    根据代码结构，设计最小化接口。而接口的设计，源于类与类之间的依赖关系。所以等价于根据依赖关系设计最小的接口。

    

    迪米特法则：

    低耦合的具体实现法则：对象之间保持的最小的了解。

    比如：A和B有耦合，B和C有耦合，那么设计的时候，如果A和C有耦合，就是不满足迪米特法则的。

    

    最后，开闭原则：

    对修改关闭，对扩展开放。

    意思就是：软件里面已经编写好的代码，不允许修改，想要扩展的功能，是可以在已有的基础上扩的。则相当于一种准则。前面五种使用的好不好，就看开闭原则实现的好不好。