欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

设计思想学习之六大原则

程序员文章站 2022-06-12 22:43:30
...

六大原则

  • 开闭原则
  • 接口隔离原则
  • 迪米特法则
  • 依赖倒置原则
  • 里氏替换原则
  • 单一职责原则

这六种原则相信网上一找一大堆,所以我也就不写一些公共的定义或者一些书面语,我只谈谈自己的学习理解。


开闭原则

开闭原则(Open Close Principle):对扩展开放,对修改关闭

很通俗易懂的一个原则,我的理解就是想要扩展功能就加新的类新的代码,以前老的代码不要去修改。

可以想想一下类似电脑内存条,内容不够了就在插一条,如果插口无限,你就可以无限插新的内存条而不是去换老的。

接口隔离原则

接口隔离原则(Interface Segregation Principle):不依赖不需要的接口,实现最小的依赖。

问题由来

public interface Animal{
    void run();
    void fly();
    void eat();
    void sleep();
}
public class Dog implements Animal{
    void run(){};
    void fly(){};
    void eat(){};
    void sleep(){};
}
public class Bird implements Animal{
    void run(){};
    void fly(){};
    void eat(){};
    void sleep(){};
}
//对于狗来说飞是没用的,对于鸟来说跑是没用,但是却又不得不实现

问题解决
把臃肿的接口拆分,让他们变小。

public interface Animal{
    void eat();
    void sleep();
}
public interface sky{void fly();}
public interface load{void run();}
public class Dog implements Animal,load{
    void run(){};
    void eat(){};
    void sleep(){};
}
public class Bird implements Animal,sky{
    void fly(){};
    void eat(){};
    void sleep(){};
}

采用接口隔离原则对接口进行约束时,要注意以下几点:

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

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

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

迪米特法则

迪米特法则(Law Of Demeter): 我的理解是不要引入非朋友类,保持最少的了解,所以也叫最少知道原则(Least Knowledge Principle 简写LKP)

问题由来
在下面的代码中其实老板完全不需要与工作有依赖

public class Boss{
    private Secretary secretary=new Secretary ();
    public void arrange(Secretary secretary){
        Work work=new Work();
        secretary.send(work);
    }
}
public class Secretary {
    public void send(Work work){
        System.out.println("传递工作任务");
        work.arrangeWork();
    }
}
public class Work{
    public void arrangeWork(){
        System.out.println("实现中国伟大复兴");
    }
}

问题解决
遵循迪米特法则

public class Boss{
    private Secretary secretary=new Secretary ();
    public void arrange(Secretary secretary){
        secretary.send();
    }
}
public class Secretary {
    private Work work=new Work();
    public void send(){
        System.out.println("传递工作任务");
        work.arrangeWork();
    }
}
public class Work{
    public void arrangeWork(){
        System.out.println("实现中国伟大复兴");
    }
}

迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。

依赖倒置原则

依赖倒置原则(Dependence Inversion Principle):我的理解是不要去直接依赖底层的模块,而是去依赖接口,然后底层去实现接口

问题由来
假如我现在正在看有关java方面的书学习java

public void My{
    public void study(JavaBook javaBook){
        System.out.print("正在看");
        javaBook.read();
    } 
}
public void JavaBook{
    public void read(){
        System.out.println("JAVA书籍学习");
    }
}

现在我想学C了,发现还要改动My的方法。

public void CBook{
    public void read(){
        System.out.println("C语言书籍学习");
    }
}

问题解决
抽象出一本书

public interface Book{
    void read();
}
public void JavaBook implements Book{
    public void read(){
        System.out.println("JAVA书籍学习");
    }
}
public void CBook implements Book{
    public void read(){
        System.out.println("C语言书籍学习");
    }
}
public void My{
    public void study(Book book){
        System.out.print("正在看");
        book.read();
    } 
}

我现在就是想看啥书就看啥书了

在实际编程中,我们一般需要做到如下3点:

  • 低层模块尽量都要有抽象类或接口,或者两者都有。
  • 变量的声明类型尽量是抽象类或接口。
  • 使用继承时遵循里氏替换原则。

总之,依赖倒置原则就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

里氏替换原则

里氏替换原则(Liskov Substitution Principle):我的理解是当继承的时候,尽量不要去重写父类方法,也不要重载父类的方法。

里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。

反面例子

public class Animalpublic void run(){System.out.println("欢快的跑")}
}
public class Dog extends Animal{
    @Override
    public void run(){System.out.println("二哈")}
}
//本意是想扩展父类的方法输出:二哈欢快的跑。
//结果却变成了二哈

它有下面四层含义:

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

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

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

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

单一职责原则

单一职责原则(Single Responsibility Principle):我的理解是专心只做一件事情。即一个类只负责一项职责。

假如一个类有有两个职责A和B,而当职责A发生改变并出现出错,难免会影响到职责B,出现不必要的麻烦。而运用了单一职责的话,把两个职责分为两个类,就算A改动也不会对B产生影响。

遵循单一职责原的优点有:

  • 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;

  • 提高类的可读性,提高系统的可维护性;

  • 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。

需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。

相关标签: 设计