设计模式六大原则之----单一职责原则

前端之家收集整理的这篇文章主要介绍了设计模式六大原则之----单一职责原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

一、定义

规定一个类只有一个发生变化的原因。通俗理解为:一个类只负责一项职责。

友情提醒:xmind导出的图片有点模糊,请放大查看

二、 问题的由来

2.1 问题

类T负责两个不同的职责,当职责P1改变需求时需要修改T类,这时候就有可能因为修改的逻辑导致职责P2出现故障

2.2 解决方

遵循单一原则,创建两个类T1和T2,在修改T1的时候不会影响T2,同理,修改T2的时候也不影响T1的逻辑

三、 特点

  • 降低类的复杂度,每个类和接口都有清晰明确的定义
  • 提高代码可读性
  • 提高代码可维护性
  • 降低变更引起的风险

四、 重点

  • 接口遵循单一职责。
    • 例如:ListView中的itemClick和itemLongClick都有不同的接口
  • 类的单一职责比较难以实现,尽量做到只有一个原因引起变化
  • 方法遵循单一原则
    • 一个方法尽可能只做一件事,能分解就分解,分解到原子级别

五、案例

创建一个动物类,告诉系统,这些动物都是呼吸什么的。

5.1 实现需求

功能类:

class Aniaml{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸空气");
    }
}

调用逻辑:

Aniaml aniaml = new Aniaml();
aniaml.breath("牛");
aniaml.breath("羊");

执行结果:

11-14 19:16:59.752 28316-28316/? E/MainActivity: 牛呼吸空气
11-14 19:16:59.753 28316-28316/? E/MainActivity: 羊呼吸空气

5.2 解决BUG

由于之前实现的时候没有考虑到水生动物,它是呼吸水的,而不是呼吸空气的。

普通代码处理(不遵循单一职责原则):

class Aniaml{
    public void breath(String animal){
        // 这里是水生动物判断条件,简单表示
        if ("鱼".equals(animal)){
            Log.e(TAG,animal+"呼吸水");
        }else{
            Log.e(TAG,animal+"呼吸空气");
        }
    }
}

添加breath(“鱼”),执行结果:

11-14 19:20:23.927 30833-30833/com.designpatterndisclipline E/MainActivity: 牛呼吸空气
11-14 19:20:23.927 30833-30833/com.designpatterndisclipline E/MainActivity: 羊呼吸空气
11-14 19:20:23.927 30833-30833/com.designpatterndisclipline E/MainActivity: 鱼呼吸水

这种方式修改的简单,但是会埋下隐患,目前代码逻辑比较少,不会出问题,如果再复杂的话,有可能某天运行后结果会是牛呼吸水,这就比较尴尬了。

5.3 完全遵循单一职责原则解决BUG

完全遵循单一职责原则,则需要把Animal拆分成两个类,一个呼吸水一个呼吸空气

class Animal1{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸水");
    }
}
class Animal2{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸空气");
    }
}

客户端调用逻辑:

Animal1 aniam1 = new Animal1();
Animal2 aniam2 = new Animal2();
aniam2.breath("牛");
aniam2.breath("羊");
aniam1.breath("鱼");

运行结果:

11-14 19:26:06.400 2693-2693/com.designpatterndisclipline E/MainActivity: 牛呼吸空气
11-14 19:26:06.400 2693-2693/com.designpatterndisclipline E/MainActivity: 羊呼吸空气
11-14 19:26:06.400 2693-2693/com.designpatterndisclipline E/MainActivity: 鱼呼吸水

这种方案完全遵循单一职责原则,完全解决了BUG,但是在实际情况中,这种情况还是比较少见的,因为一个类不会像例子里那么简单,相当复杂,如果为了一个BUG,把一个类拆分成两个类,工作量是非常大的,也是不可取的。

5.4 方法遵循单一职责原则解决该BUG

在原先的Animal类中添加一个方法来处理水生动物呼吸的逻辑,在调用的时候修改调用方法即可。

class Animal{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸空气");
    }
    public void breath1(String animal){
        Log.e(TAG,animal+"呼吸水");
    }
}

客户端调用逻辑:

Animal aniaml = new Animal();
aniaml.breath("牛");
aniaml.breath("羊");
aniaml.breath1("鱼");

执行结果:

11-14 19:31:03.231 6189-6189/? E/MainActivity: 牛呼吸空气
11-14 19:31:03.231 6189-6189/? E/MainActivity: 羊呼吸空气
11-14 19:31:03.231 6189-6189/? E/MainActivity: 鱼呼吸水

最后这种解决办法虽然没有完全遵循单一职责原则,但是遵循了方法的单一职责,相较完全的遵循单一职责要优雅得多,所以,在项目构建过程中,并不一定完全按照6大原则进行。

原文链接:https://www.f2er.com/javaschema/282470.html

猜你在找的设计模式相关文章