码迷,mamicode.com
首页 > 其他好文 > 详细

万字总结之设计模式七大原则

时间:2020-06-02 13:36:38      阅读:55      评论:0      收藏:0      [点我收藏+]

标签:存在   static   依据   重用   多个   run方法   manage   完全   void   

前言

上篇说了反射,将其作为框架的基础知识。还没看过的移至传送门,万字总结之反射(框架之魂)。今天我们来看设计模式。话不多说,let‘s go。

技术图片

什么是设计模式?

设计模式是对软件设计普遍存在的问题,所提出的解决方案。

与项目本身没有关系,不管是电商,ERP,OA 等,都可以利用设计模式来解决相关问题。

当然如果这个软件就只有一小部分人用,并且功能非常简单,在未来可预期的时间内,不会做任何大的修改和添加,即可以不使用设计模式。但是这种的太少了,所以设计模式还是非常重要的。

为什么要使用设计模式?

使用设计模式的最终目的是“高内聚低耦合”。

  • 代码重用性:相同功能的代码,不多多次编写
  • 代码可读性:编程规范性,便于其他程序员阅读
  • 代码可扩展性:当增加新的功能后,对原来的功能没有影响

设计模式的七大原则

设计模式有7大原则,具体如下,即这些不仅是设计模式的依据,也是我们平常编程中应该遵守的原则。

1.单一职责原则

见名知意,我们设计的类尽量负责一项功能,如A类只负责功能A,B类只负责功能B,不要让A类既负责功能A,又负责功能B,这样会导致代码混乱,容易产生bug。

未使用单一职责原则

Single类:

public class single {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽车");
        vehicle.run("轮船");
        vehicle.run("飞机");
    }
}

 

Vehicle类:

public class Vehicle {
    void run(String type){
        System.out.println(type+"在公路上开");
    }
}

 

运行结果:

技术图片

我们看下运行结果,汽车是在公路上开,但是轮船和飞机并不是在公路上。因为Vehicle类负责了不止一个功能,所以该设计是有问题的。

已使用单一职责原则

对于上面的例子,我们采用单一职责原则重写一下,将Vehicle类拆分成三个类,分别是Car,Ship,Plane,让他们各自负责陆地上,水上,空中的交通工具,使其互不影响。

如果我们需要对水上交通做“风级大于8级,禁止出海”的限制,就只需要对Ship类进行修改。

具体代码如下:

single类:

public class single {
    public static void main(String[] args) {
        Car car = new Car();
        car.run("汽车");

        Ship ship=new Ship();
        ship.run("轮船");

        Plane plane=new Plane();
        plane.run("飞机");
    }
}

 

Car类:

public class Car {
    void run(String type){
        System.out.println(type+"在公路上开");
    }
}

 

Ship类:

public class Ship {
    void run(String type){
        System.out.println(type+"在水里开");
    }
} 

 

Plane类:

public class Plane {
    void run(String type){
        System.out.println(type+"在天空开");
    }
}

 

运行结果:

技术图片

优化

我们可以发现单一职责原则有点代码太多了,显得冗余。毕竟我们程序员是能少写就少写,决不能多写代码。那我们对其优化下,上面每个类只有一个方法,我们可以合并为一个类,其中有三个方法,每个方法对应着在公路上,在水上,在天空中的交通工具,将单一职责原则落在方法层面,而不再是类层面,代码如下:

single类:

public class single {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.runOnRoad("汽车");

        vehicle.runOnWater("轮船");

        vehicle.runOnAir("飞机");
    }
}

 

Vehicle类:

 

public class Vehicle {
    void runOnRoad(String type){
        System.out.println(type+"在公路上开");
    }
    void runOnWater(String type){
        System.out.println(type+"在水里开");
    }
    void runOnAir(String type){
        System.out.println(type+"在天空开");
    }
} 

 

运行结果:

技术图片

优缺点总结

优点:

  • 降低类的复杂性,一个类只负责一个职责。
  • 提高代码的可读性,逻辑清楚明了。
  • 降低风险,只修改一个类,并不影响其他类的功能。

缺点:代码量增多。(可将单一职责原则落在方法层面进行优化)

2.接口隔离原则

类不应该依赖他不需要的接口,接口尽量小颗粒划分。

未使用接口隔离原则

People类:

public interface People {
    void exam();
    void teach();
}

 

Student类:

public class Student implements People {
    @Override
    public void exam() {
        System.out.println("学生考试");
    }

    @Override
    public void teach() {

    }
}

 

Teacher类:

public class Teacher  implements People{
    @Override
    public void exam() {

    }

    @Override
    public void teach() {
        System.out.println("教师教书");
    }
}

 

test类:

public class test {
    public static void main(String[] args){
        People student=new Student();
        student.exam();

        People teacher=new Teacher();
        teacher.teach();
    }
} 

 

运行结果:

技术图片

注:此处代码并没有报错,正常运行的,但是看得代码冗余且奇怪。Student只需要实现People的exam方法,而Teacher只需要实现People的teach方法,但是现在Student实现了People接口,就必须重写exam和teach方法,Teacher也是如此。

已使用接口隔离原则

我们将People接口的两个方法拆分开,分为两个接口People1和People2,并且让Sudent实现People1接口,Teacher实现People2接口,使其互不干扰,具体代码如下:

People1类:

public interface People1 {
    void exam();
}

 

People2类:

public interface People2 {
    void teach();
}

 

Student类:

public class Student implements People1 {
    @Override
    public void exam() {
        System.out.println("学生考试");
    }
}

 

Teacher类:

public class Teacher  implements People2 {
    @Override
    public void teach() {
        System.out.println("教师教书");
    }
} 

 

test类:

public class test {
    public static void main(String[] args){
        People1 student=new Student();
        student.exam();

        People2 teacher=new Teacher();
        teacher.teach();
    }
}

 

运行结果:

技术图片

总结

言归正传,如果将多个方法合并为一个接口,再提供给其他系统使用的时候,就必须实现该接口的所有方法,那有些方法是根本不需要的,造成使用者的混淆。

3.依赖倒转原则

高层模块不应该依赖底层模块,二者都应该依赖接口或抽象类。

其核心就是面向接口编程。

依赖倒转原则主要基于如下的设计理念:相对于细节的多变性,抽象的东西要稳定的多,以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。

抽象指接口或抽象类,细节指具体的实现类。

这样讲太干涩,照搬宣科,没有灵魂,说了等于没说。接下来我们用例子来说明。

未使用依赖倒转原则

由于现在是特殊时期,我们先来一个买菜的例子。如下是傻白甜的例子,未使用到依赖倒转原则。

Qingcai类:

public class Qingcai {
    public void run(){
        System.out.println("买到了青菜");
    }
} 

 

People类:

public class People {
    public void bug(Qingcai qingcai){
        qingcai.run();
    }
}

 

test类:

public class test {
    public static  void main(String[] args){
        People people=new People();
        people.bug(new Qingcai());
    }
}

  

运行结果:

技术图片

提出问题,思路转变(重点)

上述看着没啥问题,但是如果他不想买青菜,想买萝卜怎么办?我们当然可以新建一个萝卜类,再给他弄一个run方法,但是问题是People并没有操作萝卜类的方法,我们还需要在People添加对萝卜类的依赖。这样代码要修改的代码量太多了,模块与模块之间的耦合性太高,只要需要稍微有点变化,就要大面积重构,所以该设计不合理,我们看下其类图,如下:

技术图片

这种设计是一般设计的思考方式,而依赖倒转原则中的倒转是指和平常的思考方式完全相反,先从底部开始,即先从Qingcai和Luobo开始,然后想是否能抽象出什么。很明显,他们都是蔬菜,然后我们再回头重新思考如何来设计,新的设计图如下:

(请原谅我手残党,画图都画不好。。。)

技术图片

我们可以看到将低层的类抽象出一个接口Shucai,其直接和高层进行交互,而低层的一些类则不参与,这样能降低代码的耦合性,提高稳定性。

已使用依赖倒转原则

思路有了,那就来代码耍耍把。

Shucai类:

public interface Shucai {
    public void run();
}

 

Qingcai类:

public class Qingcai implements Shucai{
    public void run(){
        System.out.println("买到了青菜");
    }
}

 

Luobo类:

public class Luobo implements Shucai {
    @Override
    public void run() {
        System.out.println("买到了萝卜");
    }
}

 

People类:

public class People {
    public void bug(Shucai shucai){
        shucai.run();
    }
}

 

test类:

public class test {
    public static  void main(String[] args){
        People people=new People();
        people.bug(new Qingcai());
        people.bug(new Luobo());
    }
}

运行结果:

技术图片

总结

该原则重点在“倒转”,要从低层往上思考,尽量抽象抽象类和接口。此例子很好的解释了“上层模块不应该依赖低层模块,他们都应该依赖于抽象”。在最开始的设计中,上层模块依赖了低层模块,调整后,上层模块和低层模块都依赖于接口Shucai,依赖关系从图中可以看出来了“倒转”。

4.里氏替换原则

继承的优缺点

里氏替换原则是1988年麻省理工姓李的女士提出,它是阐述了对继承extends的一些看法。

继承的优点:

  1. 提高代码的重用性,子类也有父类的属性和方法。
  2. 提高代码的可扩展性,子类有自己特有的方法。

继承的缺点:

当父类发生改变的时候,要考虑子类的修改。

里氏替换原则是继承的基础,只有当子类替换父类时,软件功能仍然不受到影响,才说明父类真正被复用啦。

使用里氏替换原则1

子类必须实现父类的抽象方法,但不得重写(覆盖)父类的非抽象(已实现)方法。

反例

父类A:

public class A {
    public void run(){
        System.out.println("父类执行");
    }
} 

 

子类B:

public class B extends A{
    public void run(){
        System.out.println("子类执行");
    }
} 

 

测试类test:

public class test {
    public static void main(String[] args) {
        A a = new A();
        a.run();
        System.out.println("将子类替换成父类:");
        B b = new B();
        b.run();
    }
}

 

运行结果:

技术图片

注:我每次使用子类替换父类的时候,还要担心这个子类有没有可能导致问题。此处子类不能直接替换成父类,故没有遵循里氏替换原则。

使用里氏替换原则2

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

父类A:

public class A {
    public void run(){
        System.out.println("父类执行");
    }
}

 

子类B:

public class B extends A{
    public void runOwn(){
        System.out.println("子类执行");
    }
}

测试类test:

public class test {
    public static void main(String[] args) {
        A a = new A();
        a.run();

        System.out.println("将子类替换成父类:");
        B b = new B();
        b.run();

        b.runOwn();
    }
}

 

运行结果:

技术图片

注:父类A 有run方法,继承父类A的子类B有runOwn方法,测试类test先是调用A类的run方法,接着用B类替换A类,发现还是执行的是父类A的run方法,最后再调用子类B特有的方法runOwn方法。如上,说明该段代码已使用了里氏替换原则。

使用里氏替换原则3

当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。

父类A:

public class  A {
    public void run(HashMap hashMap){
        System.out.println("父类执行");
    }
}

 

子类B :

public class B extends A{
    public void run(Map map){
        System.out.println("子类执行");
    }
}

 

测试类test:

public class test {
    public static void main(String[] args) {
        A a = new A();
        a.run(new HashMap());

        System.out.println("将子类替换成父类:");
        B b = new B();
        b.run(new HashMap());

    }
}

 

运行结果:

技术图片

我们可以看到在测试类test中,将父类A替换成子类B的时候,还是显示的执行结果“父类执行”,我们可以发现他并不是重写,而是方法重载,因为参数不一样,所以他其实是对继承的规范化,为了更好的使用继承。关于是否为方法重载或重写,我们从下图看:

技术图片

如果是重写,在上图标红的位置会出现箭头,我们可以看出是实际为重载。

那如果没有使用这个规则,会是什么样?看下面的代码:

父类A:

public class  A {
    public void run(Map map){
        System.out.println("父类执行");
    }
}

 

子类B:

public class B extends A{
    public void run(HashMap hashMap){
        System.out.println("子类执行");
    }
}

 

测试test:

public class test {
    public static void main(String[] args) {
        A a = new A();
        a.run(new HashMap());

        System.out.println("将子类替换成父类:");
        B b = new B();
        b.run(new HashMap());

    }
}

 

运行结果:

技术图片

我们可以看到将子类的范围比父类大的时候,替换的子类还是执行自己的子类方法。此不符合里氏替换原则。

总结

我们平常好像也没有遵循这些里氏替换原则,程序还是正常跑。其实如果不遵循里氏替换原则,你写的代码出问题的几率会大大增加。

5.开闭原则(重点)

基本介绍

前面四个原则,单一职责原则,接口屏蔽原则,依赖倒转原则,里氏替换原则可以说都是为了开闭原则做铺垫,其是编程汇总最基础,最重要的设计原则,核心为对扩展开发,对修改关闭,简单来说,通过扩展软件的行为来实现变化,而不是通过修改来实现,尽量不修改代码,而是扩展代码。

未使用开闭原则

接口transport:

public interface transport {
    public void run();
}

 

Bus:

public class Bus implements transport {
    @Override
    public void run() {
        System.out.println("大巴在公路上跑");
    }
}

 

当我们修改需求,让大巴也能有在水里开的属性,我们可以对Bus类添加一个方法即可。但是这个已经违背了开闭原则,如果业务复杂,这样子的修改很容易出问题的。

已使用开闭原则

我们可以新增一个类,实现transport接口,并继承Bus类,写自己的需求即可。

public class universalBus extends Bus implements transport {
    @Override
    public void run() {
        System.out.println("大巴既然在公路上开,又能在水里开");
    }
}

 

6.迪米特原则

介绍

  1. 一个对象应该对其他对象保持最少的了解。
  2. 类与类关系越密切,耦合度越大
  3. 一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public 方法,不对外泄露任何信息
  4. 迪米特法则还有个更简单的定义:只与直接(熟悉)的朋友通信
  5. 直接(熟悉)的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系, 我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。
    其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量 的形式出现在类的内部。
 

把上面的概念一一翻译成人话就是:

  1. 我们这个类姑娘啊,因为太矜持了不善于社交,所以对其他类伙伴们不怎么熟悉。
  2. 类姑娘实在是太害羞了,一旦与别人多说几句话就会紧张的不知所措,频频犯错。
  3. 矜持的类姑娘尽管心思很活跃,爱多想。但是给别人的感觉都是纯洁的像一张白纸。
  4. 因为类姑娘太过于矜持,害怕陌生人,认为陌生人都是坏人,所以只与自己熟悉的朋友交流。
  5. 类姑娘熟悉的朋友有:成员变量,方法参数,方法返回值的对象。而出现在其他地方的类都是陌生人,坏人!本姑娘拒绝与你交流!!!

哈哈,这样应该大家都能理解了。总而言之就一句话:一个类应该尽量不要知道其他类太多的东西,不要和陌生的类有太多接触

未使用迪米特原则

总公司员工Employee类:

public class Employee {
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

 

分公司员工SubEmployee类:

public class SubEmployee {
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

 

总公司员工管理EmployeeManager类:

public class EmployeeManager {
    public List<Employee> setValue(){
        List<Employee> employees=new ArrayList<Employee>();
        for(int i=0;i<10;i++){
            Employee employee=new Employee();
            employee.setId("总公司"+i);
            employees.add(employee);
        }
        return  employees;
    }

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

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

}

 

分公司员工管理SubEmployeeManager类:

public class SubEmployeeManager {
    public List<SubEmployee> setValue(){
        List<SubEmployee> subEmployees=new ArrayList<SubEmployee>();
        for(int i=0;i<10;i++){
            SubEmployee subEmployee=new SubEmployee();
            subEmployee.setId("分公司"+i);
            subEmployees.add(subEmployee);
        }
        return subEmployees;
    }
}

 

测试类:

public class test {
    public static  void main(String[] args){
        EmployeeManager employeeManager=new EmployeeManager();
        SubEmployeeManager subEmployeeManager=new SubEmployeeManager();
        employeeManager.printAllEmployee(subEmployeeManager);
    }
} 

 

运行结果:

技术图片

上面的代码是正常运行的,但是可以看到一个问题,EmployeeManager类的printAllEmployee方法中使用的局部变量SubEmployee是不符合迪米特法则的,其是陌生朋友,应该拒绝沟通。

已使用迪米特原则

EmployeeManager类:

public class EmployeeManager {
    public List<Employee> setValue() {
        List<Employee> employees = new ArrayList<Employee>();
        for (int i = 0; i < 10; i++) {
            Employee employee = new Employee();
            employee.setId("总公司" + i);
            employees.add(employee);
        }
        return employees;
    }

    public void printAllEmployee(SubEmployeeManager sub) {
        sub.printAllSubEmployee();

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

}

 

SubEmployeeManager类:

public class SubEmployeeManager {
    public List<SubEmployee> setValue(){
        List<SubEmployee> subEmployees=new ArrayList<SubEmployee>();
        for(int i=0;i<10;i++){
            SubEmployee subEmployee=new SubEmployee();
            subEmployee.setId("分公司"+i);
            subEmployees.add(subEmployee);
        }
        return subEmployees;
    }

    public void printAllSubEmployee(){
        List<SubEmployee> list1 = setValue();
        for(SubEmployee e:list1){
            System.out.println(e.getId());
        }
    }
}

 

我们将EmployeeManager类printAllEmployee方法中的打印分公司的代码移到了分公司的管理类SubEmployeeManager类中,再在方法中显示的调用SubEmployeeManager类的方法,这符合迪米特法则的。

7.合成复用原则

尽量使用合成/集合,不要用继承。

如果使用继承,会使得耦合性加强,尽量作为方法的输入参数或类的成员变量,这样可以避免耦合。

结语

所有的原则只是规范,为了代码更加优雅,为了让人一目了然。如果一定不遵循原则,那代码还是可以跑的,只是日后出bug的可能性提高。

以上,简单来说,主要包括两点:

1.找出应用中需要变化的独立出来,不要和固定的混合在一起。

2.面向接口编程,而不是面向实现编程。

参考资料

设计模式六大原则(一):单一职责原则

设计模式的七大原则(1) --单一职责原则

六大设计原则之依赖倒置原则(DIP) 

设计模式之里氏替换原则

 

万字总结之设计模式七大原则

标签:存在   static   依据   重用   多个   run方法   manage   完全   void   

原文地址:https://www.cnblogs.com/chenchen0618/p/12434603.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!