设计原则

最新推荐文章于 2022-02-11 11:22:52 发布

Jalon007

最新推荐文章于 2022-02-11 11:22:52 发布

阅读量421

点赞数 1

分类专栏：设计模式

本文链接：https://blog.csdn.net/u010657219/article/details/52193781

版权

设计模式专栏收录该内容

5 篇文章 0 订阅

订阅专栏

单一职责原则

定义
一个类只负责一项职责，不要存在多于一个导致类变更的原因。
描述
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
实列：在用户管理系统中实现一个特牛接口，实现用户信息的管理和用户的管理，如下：

稍微有点强迫症的人，估计看得都会头皮发麻。怎么能将用户的属性（Property）和用户的行为（Behavior）在一个类中去实现呢，这种方式会导致用户属性和用户行为耦合度过高。把用户属性抽象成BO（Bussiness Object，业务对象），把行为抽取成BIZ(Business Logic，业务逻辑)对类图进行修正，如下：

重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。IUserBiz负责用户的行为，完成用户信息的维护和变更。我们先来看一看分拆成两个接口怎么使用。我们现在是面向接口编程，所以产生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。当然，也可以当IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当作IUserBiz的实现类就可以了。示列代码如下：

.......

IUserBiz userInfo = new UserInfo();

//我要赋值了，我就认为它是一个纯粹的BO

IUserBO userBO = (IUserBO)userInfo;

userBO.setPassword("abc");

//我要执行动作了，我就认为是一个业务逻辑类

IUserBiz userBiz = (IUserBiz)userInfo;

userBiz.deleteUser();

.......

其实，在实际的使用中，可能更倾向于使用两个不同的类或接口：一个是IUserBO，一个是IUserBiz，类图应该如图下所示。
实际类图

里氏替换原则

定义
所有引用基类的地方必须能透明地使用其子类的对象
描述
问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
实列：在设计游戏场景中，每个游戏较色可以使用各种各样的武器，类图如下：

枪的主要职责是射击，如何射击在各个具体的子类中定义，手枪是单发射程比较近，步枪威力大射程远，机枪用于扫射。在士兵类中定义了一个方法killEnemy，使用枪来杀敌人，具体使用什么枪来杀敌人，调用的时候才知道，AbstractGun类的源程序如代码如下:

public abstract class AbstractGun {

//枪用来干什么的？射击杀戮！

public abstract void shoot();

}

手枪，步枪，机枪的实现类如下：

public class Handgun extends AbstractGun {

//手 枪的特点是携带方便，射程短

@Override

public void shoot() {

System.out.println("手 枪射击...");

}

}

public class Rifle extends AbstractGun{

//步枪的特点是射程远，威力大

public void shoot(){

System.out.println("步枪射击...");

}

}

public class MachineGun extends AbstractGun{

public void shoot(){

System.out.println("机枪扫射...");

}

}

士兵的实现：

public class Soldier {

public void killEnemy(AbstractGun gun){

System.out.println("士兵开始杀人...");

gun.shoot();

}

}

场景类Client的源代码如下：

public class Client {

public static void main(String[] args) {

//产生三毛这个士兵

Soldier sanMao = new Soldier();

sanMao.killEnemy(new Rifle());

}

}

在这个程序中，我们给三毛这个士兵一把步枪，然后就开始杀敌了，如果三毛要使用机枪当然也可以,直接把sanMao.killEnemy(new Rifle())修改为 sanMao.killEnemy(new MachineGun())就可以了，在编写程序时Solider士兵类根本就不用知道是哪个型号的枪（子类）被传入。
注意:在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
步枪有几个比较如雷贯耳的型号，比如AK47、G3狙击步枪等，把这两个型号的枪引入后的Rifle子类图如图下图所示：
AK47G3
点枪(G3)只是在普通的步枪上增加了瞄准器属性。

public class G3 extends Rifle {

//狙击枪都是携带一个精准的望远镜

public void zoomOut(){

System.out.println("通过望远镜查看敌人...");

}

public void shoot(){

System.out.println("G3射击...");

}

}

狙击手源码：

public class Snipper {

public void killEnemy(G3 g3){

//首先看看敌人的情况，别杀死敌人，自己也被人干掉

g3.zoomOut();

//开始射击

g3.shoot();

}

}

public class Client {

public static void main(String[] args) {

//产生三毛这个狙击手

Snipper sanMao = new Snipper();

sanMao.killEnemy(new G3());

}

}

假如把G3 改成普通的步枪(父类对象)会怎么样呢：

public class Client {

public static void main(String[] args) {

//产生三毛这个狙击手

Snipper sanMao = new Snipper();

Rifle rifle = new Rifle();

sanMao.killEnemy((G3)rifle);

}

}

会在运行期抛出java.lang.ClassCastException异常，这也是经常说的向下转型（downcast）是不安全的，从里氏替换原则来看，就是有子类出现的地方父类未必就可以出现。上列中Rifle明显没有zoomOut方法！

依赖倒置原则

定义
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
描述
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
示列
大多数创业者都是比较穷的，否则就不用苦逼低创业了吧，哈哈。在创业初期为了业务的便利，卖了辆奇瑞轿车，类图如下：

示列源码如下：

public class Driver {

public void drive(Qirui car){

car.run();

}

}

Qirui实现

public class Qirui{

//启动奇瑞

public void run(){

System.out.println("奇瑞汽车开始运行...");

}

}

Client实现：

public class Client {

public static void main(String[] args) {

Driver zhangSan = new Driver();

Qirui qirui = new Qirui();

//张三开奇瑞车

zhangSan.drive(qirui);

}

}

可以说奇瑞车是完全可以满足目前的创业者的，但是随着资本的积累，zhangsan会越来越富有，一辆奇瑞根本就不够他装逼啊。那么问题来了，一辆奇瑞根本不能满足zhangsan日益增长的财富需求，也跟身份越来越不相称，为了面子问题，zhangsan一下子购进了数辆豪车，法拉利，大奔，宝马。。。应有尽有。。。
豪车对象都能很快实现，但若让zhangsan都开起来呢？每次开不同车时候都需要修改Client类，Client 跟Driver 和 Qirui 耦合度较高。
这只是一个简单的列子，若开发庞大的系统呢，通常是由一个团队完成，假如20人开发，各人负责不同的功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Qirui类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续……要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系,降低各个模块的耦合。
针对上面的列子，根据依赖倒置原则可以抽象成如下：

抽象接口申明：

public interface IDriver {

//是司机就应该会驾驶汽车

public void drive(ICar car);

}
public interface ICar {

//是汽车就应该能跑

public void run();

}

汽车实现：

public class Benz implements ICar{

//汽车肯定会跑

public void run(){

System.out.println("奔驰汽车开始运行...");

}

}

public class Qirui implements ICar{


public void run(){

System.out.println("奇瑞汽车开始运行...");

}

老司机的实现：

public class Driver implements IDriver{

//司机的主要职责就是驾驶汽车

public void drive(ICar car){

car.run();

}

}

Client实现：

public class Client {

public static void main(String[] args) {

IDriver gebilaowang= new Driver();

ICar benz = new Benz();

//张三开奔驰车

gebilaowang.drive(benz);

}

}

Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上。

接口隔离原则

定义
一个类对另一个类的依赖应该建立在最小的接口上
描述
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
示列

上图表示：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。代码如下：

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());  
    }  
}

可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的设计如下图：
接口隔离2
源码如下：

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");  
    }  
}

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

接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

迪米特法原则

定义
一个对象应该对其他对象保持最少的了解(解耦)。
描述
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
示列
迪米特法则又叫最少知道原则，也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
有一个集团公司，下属单位有分公司和直属部门，现在要求打印出所有下属单位的员工ID。

//总公司员工  
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());  
    }  
}

现在这个设计的主要问题出在CompanyManager中，根据迪米特法则，只与直接的朋友发生通信，而SubEmployee类并不是CompanyManager类的直接朋友（以局部变量出现的耦合不属于直接朋友），从逻辑上讲总公司只与他的分公司耦合就行了，与分公司的员工并没有任何联系，这样设计显然是增加了不必要的耦合。按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

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());  
        }  
    }  
}

修改后，为分公司增加了打印人员ID的方法，总公司直接调用来打印，从而避免了与分公司的员工发生耦合。迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

开闭原则

定义
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
描述
问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
示列
假设应用需要计算各种不同形状的体积，虽然很简单。计算所有作物的面积，如你所知，农作物有多重形状，圆形，三角形甚多多边形。
我们把计算面积的类抽象为AreaManager，这符合单一职责原则——只负责计算作物的面积。
假设有一个长方形的作物，用Rectangle类来表示。

Rectangle.Java

    public class Rectangle {
        private double length;
        private double height; 
        // getters/setters ... 
    }

AreaManager.java

    public class AreaManager {
        public double calculateArea(ArrayList<Rectangle>... shapes) {
            double area = 0;
            for (Rectangle rect : shapes) {
                area += (rect.getLength() * rect.getHeight()); 
            }
            return area;
        }
    }

AreaManager在我们碰到下一个圆形的之前都能正常工作。

Circle.Java

    public class Circle {
        private double radius; 
        // getters/setters ...
    }

既然有新的图形，我们必须修改计算面积的代码

AreaManager

    public class AreaManager {
        public double calculateArea(ArrayList<Object>... shapes) {
            double area = 0;
            for (Object shape : shapes) {
                if (shape instanceof Rectangle) {
                    Rectangle rect = (Rectangle)shape;
                    area += (rect.getLength() * rect.getHeight());                
                } else if (shape instanceof Circle) {
                    Circle circle = (Circle)shape;
                    area += (circle.getRadius() * cirlce.getRadius() * Math.PI;
                } else {
                    throw new RuntimeException("Shape not supported");
                }            
            }
            return area;
        }
    }

代码写到这里已经感觉不对劲了，如果继续遇到三角形，或者其他的图形，我们必须不断重复修改这个类。
这个类违背了开/闭原则，它既没有关闭对类的修改，也要没有对类进行拓展，每一次新图形出现我们必须修改AreaManager，所以要避免这种情况的发生。
通过继承实现开/闭原则
既然AreaManager是负责计算图形的面积，而每个图形都有独立的计算方法，最符合逻辑的就是把计算面积转移到每个图形类里。我们可以让所有图形类都实现一个接口Shape。

Shape.Java

    public interface Shape {
        double getArea(); 
    }

每个类都会实现这个接口：

Rectangle.Java

    public class Rectangle implements Shape {
    private double length;
    private double height; 
    // getters/setters …

    @Override
    public double getArea() {
        return (length * height);
    } }

Circle.Java

        public class Circle implements Shape {
            private double radius; 
            // getters/setters ...

            @Override
            public double getArea() {
                return (radius * radius * Math.PI);
            }
        }

我们可以使用在AreaManager中使用抽象方法，使其符合开/闭原则。


    public class AreaManager {
        public double calculateArea(ArrayList<Shape> shapes) {
            double area = 0;
            for (Shape shape : shapes) {
                area += shape.getArea();
            }
            return area;
        }
    }

总结

这里写图片描述
本文主要参考资料:
卡奴达摩的专栏
 设计模式

Jalon007

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
设计原则

单一职责原则定义一个类只负责一项职责，不要存在多于一个导致类变更的原因。描述问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T
复制链接

扫一扫

专栏目录