前言

Github:https://github.com/HealerJean

博客:http://blog.healerjean.com

image-20210706205043822

1、单一职责

1.1、解释:

官方定义:

就一个类(接口、结构体、方法等等)而言,有且仅有一个引起它变化的原因。

个人理解:

通俗的来讲做一件事就是专注做一件事,不可以三心二意。任务对象只是专注于一项职责,不去承担太多的责任。当任务对象的职责发生变化时,不会对其他的对象产生影响。

1.1、应用

背景:有一个类A,他需要负责T1T2。但是当职责T1因为需求而改变类A的时候,就会对职责T2造成影响,导致T2不能正常工作。

解决办法:针对职责T1创建类A,针对职责T2创建类B。这样就可以达到当修改类A时不会对职责T2造成影响,当修改类B时不会对职责T1造成影响。

2、里氏替换原则

2.1、解释:

官方定义:里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。

里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现

LSP 是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为

个人理解:子类可以扩展父类的功能,但不能改变父类原有的功能,子类中尽量不要去重写父类方法,A类的所有方法都被B类重写了。 那何必继承呢?直接新建一个B类不就好了,采用final 的手段强制来遵循

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

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

⬤ 当子类的方法重载父类的方法时,方法的前置条件要比父类方法的输入参数更宽松。

⬤ 子类的方法实现父类的抽象方法时,方法的返回值要比父类的返回值更加严谨。

2.2、反例

问题1::为什么当Rectangle替换为Square之后,面积的结果出错了呢?

答案:因为在Square类里重写了area()方法,很明显违背了里氏替换原则,改变了父类的原有功能,所以导致输出结果不对。

@Data
@AllArgsConstructor
public class Rectangle {

	private int width;
	private int height;
	public int area() {
		return width * height;
	}

}


@Data
@AllArgsConstructor
public class Square extends Rectangle {

	public int area() {
		return width * width;
	}
}


public class Tester {

  public static void main(String[] args) {
    Rectangle rectangle = new Rectangle(10, 20);
    System.out.println("面积:" + rectangle.area());
    // 输出结果为面积:200

    Square rectangle = new Square(10, 20);
    System.out.println("面积:" + rectangle.area());
    // 输出结果为面积:0
  }
}


3、依赖倒置原则

3.1、解释

所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体,依赖倒置原则的核心就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现,如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要手段。

定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

通俗点说:要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。

依赖倒置需遵循规则:

低层模块尽量都要有抽象类或接口,或者两者都有。【可能会被人用到的】

变量的声明类型尽量是抽象类或接口。

使用继承时遵循里氏替换原则。

3.2、反例:

反例:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。 这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。

解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。

class Book{
    public String getContent(){
        return "很久很久以前有一个阿拉伯的故事……";
    }
}

class Mother{
    public void narrate(Book book){
        System.out.println("妈妈开始讲故事");
        System.out.println(book.getContent());
    }
}

public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
    }
}

代码解释:上述是面向实现的编程,即依赖的是Book这个具体的实现类;看起来功能都很OK,也没有什么问题。运行良好

问题1:假如有一天,需求变成这样:不是给书而是给一份报纸,让这位母亲讲一下报纸上的故事,报纸的代码如下:

class Newspaper{
    public String getContent(){
        return "林书豪38+7领导尼克斯击败湖人……";
    }
}

这位母亲却办不到,因为她居然不会读报纸上的故事,这太荒唐了,只是将书换成报纸,居然必须要修改Mother才能读。假如以后需求换成杂志呢?换成网页呢?还要不断地修改Mother,这显然不是好的设计。原因就是MotherBook之间的耦合性太高了,必须降低他们之间的耦合度才行

3.3、正例

所以:我们引入一个抽象的接口IReader。读物,只要是带字的都属于读物:

class Newspaper implements IReader {
    public String getContent(){
        return "林书豪17+9助尼克斯击败老鹰……";
    }
}
class Book implements IReader{
    public String getContent(){
        return "很久很久以前有一个阿拉伯的故事……";
    }
}

class Mother{
    public void narrate(IReader reader){
        System.out.println("妈妈开始讲故事");
        System.out.println(reader.getContent());
    }
}

public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

4、接口隔离原则

4.1、解释:

原定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上,

问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。

**解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。 **

建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少

⬤ 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。

⬤ 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。

⬤ 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

4.2、反例

下图具体来说:

1、类A·依赖接口I中的方法1、方法2、方法3,类B是对类A依赖的实现。

2、类C依赖接口I中的方法1、方法4、方法5,类D是对类C依赖的实现。

3、对于类B和类D来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口I,所以也必须要实现这些用不到的方法。对类图不熟悉的可以参照程序代码来理解,代码如下:

image-20210708150714893

interface I {
    public void method1();
    public void method2();
    public void method3();
    public void method4();
    public void method5();
}

class A{
    public void depend1(I i){
        i.method1();
    }
    public void depend2(I i){
        i.method2();
    }
    public void depend3(I i){
        i.method3();
    }
}

class B implements I{
    public void method1() {
        System.out.println("类B实现接口I的方法1");
    }
    public void method2() {
        System.out.println("类B实现接口I的方法2");
    }
    public void method3() {
        System.out.println("类B实现接口I的方法3");
    }
    //对于类B来说,method4和method5不是必需的,但是由于接口A中有这两个方法,
    //所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
    public void method4() {}
    public void method5() {}
}

class C{
    public void depend1(I i){
        i.method1();
    }
    public void depend2(I i){
        i.method4();
    }
    public void depend3(I i){
        i.method5();
    }
}

class D implements I{
    public void method1() {
        System.out.println("类D实现接口I的方法1");
    }
    //对于类D来说,method2和method3不是必需的,但是由于接口A中有这两个方法,
    //所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
    public void method2() {}
    public void method3() {}

    public void method4() {
        System.out.println("类D实现接口I的方法4");
    }
    public void method5() {
        System.out.println("类D实现接口I的方法5");
    }
}

public class Client{
    public static void main(String[] args){
        A a = new A();
        a.depend1(new B());
        a.depend2(new B());
        a.depend3(new B());
        
        C c = new C();
        c.depend1(new D());
        c.depend2(new D());
        c.depend3(new D());
    }
}

4.3、正例

如果将这个设计修改为符合接口隔离原则,就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口。

image-20210708151511003

interface I1 {
    public void method1();
}

interface I2 {
    public void method2();
    public void method3();
}

interface I3 {
    public void method4();
    public void method5();
}

class A{
    public void depend1(I1 i){
        i.method1();
    }
    public void depend2(I2 i){
        i.method2();
    }
    public void depend3(I2 i){
        i.method3();
    }
}

class B implements I1, I2{
    public void method1() {
        System.out.println("类B实现接口I1的方法1");
    }
    public void method2() {
        System.out.println("类B实现接口I2的方法2");
    }
    public void method3() {
        System.out.println("类B实现接口I2的方法3");
    }
}

class C{
    public void depend1(I1 i){
        i.method1();
    }
    public void depend2(I3 i){
        i.method4();
    }
    public void depend3(I3 i){
        i.method5();
    }
}

class D implements I1, I3{
    public void method1() {
        System.out.println("类D实现接口I1的方法1");
    }
    public void method4() {
        System.out.println("类D实现接口I3的方法4");
    }
    public void method5() {
        System.out.println("类D实现接口I3的方法5");
    }
}

5、迪米特法则(最少知道原则)

5.1、解释

为什么叫最少知道原则:

就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样,当一个模块修改时,就会尽量少的影响其他的模块,扩展会相对容易,这是对软件实体之间通信的限制,它要求限制软件实体之间通信的宽度和深度。

定义:一个对象应该对其他对象保持最少的了解。

**通俗的来讲:就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。 **

问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。

解决方案:尽量降低类与类之间的耦合。过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合

1、个方法尽量不引入一个类中不存在的对象

2、尽量不要公布太多的public方法和非静态的public变量

3、如果一个方法放在本类中,既不增加类间的关系,也对本类不产生负面影响,那就放置在本类中

5.2、反例

举一个例子:有一个集团公司,下属单位有分公司和直属部门,现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

反例原因:现在这个设计的主要问题出在CompanyManager中,根据迪米特法则,只与直接的朋友发生通信,而SubEmployee类并不是CompanyManager类的直接朋友(以局部变量出现的耦合不属于直接朋友),从逻辑上讲总公司只与他的分公司耦合就行了,与分公司的员工并没有任何联系,这样设计显然是增加了不必要的耦合。

//总公司员工
class Employee{
  private String id;
  public void setId(String id){
    this.id = id;
  }
  public String getId(){
    return id;
  }
}

//分公司员工
class SubEmployee{
  private String id;
  public void setId(String id){
    this.id = id;
  }
  public String getId(){
    return id;
  }
}

class SubCompanyManager{
  public List<SubEmployee> getAllEmployee(){
    List<SubEmployee> list = new ArrayList<SubEmployee>();
    for(int i=0; i<100; i++){
      SubEmployee emp = new SubEmployee();
      //为分公司人员按顺序分配一个ID
      emp.setId("分公司"+i);
      list.add(emp);
    }
    return list;
  }
}

class CompanyManager{

  public List<Employee> getAllEmployee(){
    List<Employee> list = new ArrayList<Employee>();
    for(int i=0; i<30; i++){
      Employee emp = new Employee();
      //为总公司人员按顺序分配一个ID
      emp.setId("总公司"+i);
      list.add(emp);
    }
    return list;
  }

  public void printAllEmployee(SubCompanyManager sub){
    List<SubEmployee> list1 = sub.getAllEmployee();
    for(SubEmployee e:list1){
      System.out.println(e.getId());
    }

    List<Employee> list2 = this.getAllEmployee();
    for(Employee e:list2){
      System.out.println(e.getId());
    }
  }
}

public class Client{
  public static void main(String[] args){
    CompanyManager e = new CompanyManager();
    e.printAllEmployee(new SubCompanyManager());
  }
}

5.3、正例

按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合。修改后,为分公司增加了打印人员ID的方法,总公司直接调用来打印,从而避免了与分公司的员工发生耦合。

class SubCompanyManager{
    public List<SubEmployee> getAllEmployee(){
        List<SubEmployee> list = new ArrayList<SubEmployee>();
        for(int i=0; i<100; i++){
            SubEmployee emp = new SubEmployee();
            //为分公司人员按顺序分配一个ID
            emp.setId("分公司"+i);
            list.add(emp);
        }
        return list;
    }
    public void printEmployee(){
        List<SubEmployee> list = this.getAllEmployee();
        for(SubEmployee e:list){
            System.out.println(e.getId());
        }
    }
}

class CompanyManager{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<Employee>();
        for(int i=0; i<30; i++){
            Employee emp = new Employee();
            //为总公司人员按顺序分配一个ID
            emp.setId("总公司"+i);
            list.add(emp);
        }
        return list;
    }
    
    public void printAllEmployee(SubCompanyManager sub){
        sub.printEmployee();
        List<Employee> list2 = this.getAllEmployee();
        for(Employee e:list2){
            System.out.println(e.getId());
        }
    }
}

6、开闭原则

6.1、解释

解释:开闭原则就是说对扩展开放,对修改关闭

定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。

问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。

解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。

ContactAuthor