狄米特法则

狄米特法则(Law of Demeter)是指一个对象应该对其他对象保持最小的了解，又叫最少知道原则(Least Konwledge Principle)，尽量降低类与类之间的耦合度。简单的说，就是只与你直接的朋友联系，不要和不相关的人产生大量通信，如果两个类不彼此通信，那么两个类就不应到发生直接的相互作用,如果其中的一个类需要调用另一个类的方法的话,可以通过第三者转发这个调用。
作用
降低了类和类之间的耦合
现在来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程(Course)数量。这时候，TeamLeader 要找到员工 Employee 去进行统计，Employee 再把统计结果告诉 TeamLeader
1、不遵循狄米特法则
课程类

public class Course { }

Employee类进行统计

public class Employee { 
    public void checkNumberOfCourses(List<Course> courseList)
    { 
        System.out.println("目前已发布的课程数量是：" + courseList.size()); 
    } 
}

TeamLeader类

public class TeamLeader { 
      public void commandCheckNumber(Employee employee)
      { 
          List<Course> courseList = new ArrayList<Course>();
           for (int i= 0; i < 20 ;i ++){ 
              courseList.add(new Course());                 
           }
          employee.checkNumberOfCourses(courseList); 
      } 
}

执行

public static void main(String[] args) { 
    TeamLeader teamLeader = new TeamLeader(); 
    Employee employee = new Employee();     
    teamLeader.commandCheckNumber(employee); 
}

其实功能已经都已经实现，代码看上去也没什么问题。根据迪米特原则，TeamLeader 只想要结果，不需要跟 Course 产生直接的交流。而 Employee 统计需要引用 Course 对象。TeamLeader 和 Course 并不是朋友

image.png

public class Employee { 
      public void checkNumberOfCourses(){ 
          List<Course> courseList = new ArrayList<Course>(); 
          for (int i= 0; i < 20 ;i ++){ 
            courseList.add(new Course()); 
          }
          System.out.println("目前已发布的课程数量是："+courseList.size()); 
    } 
}

TeamLeader类

public class TeamLeader { 
      public void commandCheckNumber(Employee employee){           
            employee.checkNumberOfCourses(); 
      } 
}

此时的TeamLeader里不存在Course相关信息了。查看类图

image.png

里氏替换原则

里氏替换原则(Liskov Substitution Principle)有两个定义
1、如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型
2、所有引用基类的地方必须能透明地使用其子类的对象
问题由来
有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方案
当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。其实也是系统拓展性的具体体现。

1、不遵循里式替换原则
假若我们有一个功能是进行两个整数的相减

public class FunctionA {
    public int func1(int a,int b){
        return a-b;
    }
}

后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：
①两数相减
②两数相加再加100
由于类A已经实现了第一个功能，所以类B继承类A后，只需要再完成第二个功能就可以了

public class FunctionB extends FunctionA{
    public int func1(int a, int b) {
        return a+b;
    }
    public int func2(int a, int b) {
        return func1(a,b)+100;
    }
}

执行

public class main {
    public static void main(String[] args) {
        FunctionA a = new FunctionA();
        System.out.println("FunctionA:100-50="+a.func1(100,50));
        FunctionB b = new FunctionB();
        System.out.println("FunctionB:100-50="+b.func1(100,50));
        System.out.println("FunctionB:100+50+100="+b.func2(100,50));
    }
}

FunctionA:100-50=50
FunctionB:100-50=150
FunctionB:100+50+100=250
我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法，造成所有运行相减功能的代码全部调用了类B重写后的方法，造成原本运行正常的功能出现了错误。在本例中，引用基类A完成的功能，换成子类B之后，发生了异常。在实际编程中，我们常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的几率非常大。如果非要重写父类的方法，比较通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义:
①子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
②子类中可以增加自己特有的方法
③当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松
④当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格
2、使用里式替换原则
创建一个基类，使FunctionA和FunctionB都继承它。(此处使用组合方式)

public class Base {
}

public class FunctionA extends Base{
    public int func1(int a,int b){
        return a-b;
    }
}

public class FunctionB extends Base{
    FunctionA a = new FunctionA();
    public int func1(int a, int b) {
        return a+b;
    }
    public int func2(int a, int b) {
        return func1(a,b)+100;
    }
    public int func3(int a,int b) {
        return this.a.func1(a,b);
    }
}

此时FunctionB中声明了FunctionA，是一种组合的方式。再想做减法就可以直接运行func3方法

public class main {
    public static void main(String[] args) {
        FunctionA a = new FunctionA();
        System.out.println("FunctionA:100-50="+a.func1(100,50));
        FunctionB b = new FunctionB();
        System.out.println("FunctionB:100-50="+b.func3(100,50));
        System.out.println("FunctionB:100+50+100="+b.func2(100,50));
    }
}

FunctionA:100-50=50
FunctionB:100-50=50
FunctionB:100+50+100=250

合成复用原则

合成复用原则（Composite/Aggregate Reuse Principle）是指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。
简单的说，如果B类仅仅需要使用A类中的方法，尽量不去继承A类，而是通过对象组合和聚合的方式。因为对继承A类对B类来说耦合性太高，如果B类只需要使用到A类的2个方法，但是实际A类中有N个方法。那么这其余的N-2个方法也都被继承下来了。再者，如果A类的方法改变也会影响到B类。
假设A类如下：

public class A {
    public void func(){}
}

使用合成复用原则
①合成(类似依赖) has-a

public class B {
    public void Func1(A a){
        System.out.println("通过依赖引入A");
        a.func();
    }
}

②聚合 has-a

public class B1 {
    private A a;
    public void setA(A a){
        System.out.println("通过聚合的方式引入A");
        this.a =a;
    }
}

③组合Contains-a

public class B2 {
    A a = new A();
    public void func1(){
        System.out.println("通过组合的方式引入A");
        a.func();
    }
}

设计原则小结

核心思想
①找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混合在一起
②针对接口编程，而不是针对实现编程
③为了交互对象之间的松耦合设计而努力
学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。