设计模式六大原则之白话讲解

前言

一个好的程序猿，不应该只是埋头code，更不应该只懂得CV大法（“什么设计模式、架构设计，老夫撸代码就是一把梭”）。个人认为，一段好的代码，离不开算法和设计模式。

概述

设计模式有六大原则，分别为单一职责原则、开放封闭原则、里氏替换原则、依赖倒置原则、迪米特原则和接口隔离原则。
接下来，分别对这六大原则进行学习、分析。

1.单一职责原则

定义

就一个类而言，引起他变化的原因应该有且仅有一个！

解释

字面意思理解，就是only you！也就是避免一个类过度的把一些“功能”耦合在一起，即不要让这个类承担太多的功能职责。功能1发生改变，会影响功能2、功能3…等其他功能的“能力发挥”。

举个栗子

比方说我想喂养一直宠物，要求不高，能吃能睡就行。

public class Pet{public void eat(){System.out.print("吃得饱");}}

然后我就去宠物店了…

public class PetStore{public void buy(){System.out.print("宠物店买一只宠物");}}

然后宠物店老板很热情的向我推荐了二哈、拉布拉猪、泰日天、拖拉基、沙皮、金毛…并且分别介绍了它们饮食起居的不同…

public class Pet{public void eat(String kind){if (kind.equals("二哈")){System.out.print("二哈拆家，吃卫生纸");}else if (kind.equals("拉不拉猪")){System.out.print("拉不拉猪吃得多，拉得多");}else if......}}

到最后，我都不知道要把谁带回家了…是不是要疯了的节奏？早知道就为二哈、拉不拉猪、泰日天…它们单独建立一个类，自己负责自己的吃喝，我就可以当甩手大掌柜的了！

2.开放封闭原则

定义

类、模块、函数都应该是可扩展的，但不可修改

解释

对于扩展开放，对于修改就关闭。需求千变万化，我们写代码最初就应该考虑到以后的扩展性。总不能需求改了，代码就得翻天覆地吧？我做完了查询功能，需求又先后加了修改、删除…总之一句话，不要改以前的代码，要去加代码扩展

举个栗子

买了一只二哈带回家，就开始养它呗

public class PetStore{public void host(){System.out.print("养狗");}}

跟它相处了几天，很高兴哈。后来发现不行啊，除了每天喂食，这狗特么到处拉屎…好么，再给他铲屎。然后出去扔个垃圾个功夫，回到家看到的一幕，突然感觉血压有点高。这还是我家么？我是不是走错了？这是哪？（来自灵魂深处的三连问…）

//按照开发封闭原则，这么写是不对滴，毕竟代码已经改了...
public class PetStore{//传参，根据参数值来执行喂食、遛狗、铲屎方法public void host(int i){System.out.print("养狗");}}

扔完垃圾，血压一高，还得再加一个“炖狗”方法，还得接着“遭罪”…
采用开发封闭原则，就是增加一个抽象的功能类，使喂食、遛狗、铲屎成为这个抽象功能类的子类。如果我们要加入葱姜蒜炖狗，不需要动原来的方法，只需要增加一个功能类的子类实现功能类的方法即可。

3.里氏替换原则

定义

所有引用基类（父类）的地方，必须能够透明的使用其子类对象（LSP）。

解释

在代码中使用父类对象的地方替换成子类对象没事，反过来就不行。里氏替换原则是实现开放封闭原则的重要方式之一，尽量使用父类类型定义对象，运行时在确定子类类型，用子类对象来替换父类对象。
值得注意的是，子类中所有的方法必须得在父类中声明，换言之子类必须实现父类声明的所有方法。这里尽量把父类声明为抽象类、接口，使子类继承父类或实现父类接口，并实现父类中声明的方法。在运行时，子类实例替换父类实例，既方便功能扩展，又不至于对源代码大张旗鼓的改动。若新增一个功能，就新增一个子类实现即可。

举个栗子

我新建一个类继承Pet类

public class Dog extends Pet{public void eat(){System.out.print("爱吃骨头");}}

违反规则了…虽然Pet > Dog，但是子类仅可以扩展新功能，不能改变父类原本的功能。这里如果我把用到Pet的地方都换成Dog，那岂不是乱了？所有的宠物都吃骨头？至少加菲猫不吃骨头吧？荷兰猪也不吃骨头啊！

4.依赖倒置原则

定义

高层模块不应依赖低层模块，他们都应该依赖抽象。抽象不依赖细节，细节依赖抽象

解释

抽象指接口、抽象类（都不能直接被实例化），细节指实现类（实现接口、继承抽象类）。高层模块指调用端，低层模块指具体实现类。请求网络既可以用okhttp，也可以用原生API，只需要封装一个网络请求接口，创建他俩的接口实现类就行了。

举个栗子

购买宠物，当然还得买狗粮、猫粮，这玩意不能混，你混了关键它也不吃啊…

public class PetStore{public void buy(Dog dog){System.out.print("宠物店买一只二哈，再买狗粮");}public void buy(Cat cat){System.out.print("宠物店买一只加菲猫，还买猫粮");}//这里省略了鸡鸭鹅狗猪的购买方法...}

如果按照上面的方式去购买，那不得累死？换个思路！宠物店老板啥也不干，就守在门口收银台收钱。你买猫粮、狗粮老板不管，你买加菲猫肯定会在货架上拿猫粮，买二哈肯定在货架上拿骨头。这样老板就不操心了，你买完了过来掏钱就行了…
面向接口编程，完美！

public interface Pet{public void buy();}public class Dog implements Pet{@Overridepublic void buy() {System.out.print("买一只二哈回家，还给它买骨头吃");}}

buy方法是高层模块，买猫买狗是低层模块。依赖于抽象，扩展性贼强！

5.迪米特原则

定义

一个软件实体，应尽可能少的与其他实体发生作用。

解释

也叫最少知道原则。当一个模块发生修改时，应该尽可能少的减少对象间的交互和影响其他模块。若两个对象之间不发生直接通信，他俩就不会发生直接作用。如果要调用对方的方法，需要引入第三者或中介。

举个栗子

狗子病了就得宠物医院看病

public class Hospital{public void doctor(){System.out.print("医生看病");}}

医生看病得知道狗子平常都有什么不良习惯，比如拆家、撕卫生纸…很显然，铲屎官对这些都有切身体会，医生直接询问铲屎官就好了。当然了，你也可以直接问二哈，就算它不咬你，你也得费半天劲，你得先陪他玩、喂零食、摸头杀…（但是这就违背迪米特原则）

public class Owner{public void getInformation(){System.out.print("铲屎官知道狗子信息...");}}

6.接口隔离原则

定义

一个类对另一个类的依赖，应该建立在最小的接口上。

解释

接口一定要细化，接口中的方法一定要少，切忌接口臃肿化。

举个栗子

如果把所有方法都定义在一个接口中

public interface Pet{public void eat();public void wang();//二哈汪汪叫public void miao();//加菲猫喵喵}

创建Dog类，此时接口已经变得臃肿了，加菲猫自己的方法在此并未用到，gg…

public class Dog implements Pet{@Overridepublic void eat() {System.out.print("狗吃肉");}@Overridepublic void wang() {System.out.print("二哈旺旺叫...");}@Overridepublic void miao() {//加菲猫喵喵叫，这里用不到，接口已经臃肿了...}}

这里只好把接口拆开，组合实现：

public interface Wang{public void wang();}

public class Dog implements Wang{@Overridepublic void wang() {System.out.print("二哈旺旺叫...");}}

我想，通过上面的几个栗子，大家应该对设计模式的六大原则都有了清楚的认识。“官方语言”不好懂，通过几个生动的案例可以帮助理解，记忆也会更深刻。这样如果哪天大家面试的时候被问到了，也不会因为紧张而“短路”。比如面试官问啥是迪米特原则？一紧张忘了怎么办？大脑一片空白就一个名词——“第三者”。先把这个词扔给他，然后再慢慢解释啥是“第三者”（迪米特原则），希望能帮到大家！