单一职责原则

单一职责原则:一个类应该只有一个原因引起改变,即一个类应该只负责一个业务逻辑。

问题由来:类T负责t1, t2两个职责,当因为t1j对类T修改的时候,可能导致类T出现问题而影响职责t2。

解决方案:遵循单一职责原则,将类T进行改写,确保一个类负责一个职责。

demo:

有一个类Animal,具有方法breath功能,一般的思路是这样子设计的:

class Animal {
public void breathe(String animal) {
System.out.println(animal + "呼吸空气");
} }

当你创建一个Animal实例后,就可以调用breathe方法了。

public class SingletonResponsibility {
public static void main(String[] args) {
Animal animal = new Animal();
animal.breathe("鸟类");
animal.breathe("狮子");
//逻辑错误:鱼类应该呼吸水
animal.breathe("鱼类");
}
}

我们发现,当调用breathe方法时,若是传入鱼类,输出结果不会发生变化。但是,这在逻辑上面是错误的。

##################

改进思路1:在breathe方法中进行判断

通过判断,区别对待:若是鱼类,则输出“呼吸水”;其他的动物,输出“呼吸空气”;

这样做的好处是:能够爆出业务逻辑的正确;但是违反了单一职责原则:类Animal除了负责正常的业务罗杰,还需要进行类型判断。

class Animal1 {
public void breathe(String animal) {
// 改进: 在方法中对animal进行判断,如果是鱼类,则显示呼吸水
// 弊端: 没有尊新单一职责原则,该方法除了需要执行正常的业务逻辑外,
// 还需要对animal进行判断。
if ("鱼类".equals(animal)) {
System.out.println(animal + "呼吸水");
} else {
System.out.println(animal + "呼吸空气");
}
}
}

改进思路2:对类、方法进行拆分

为了保证遵循单一职责原则,我们可以将类、方法进行拆分,并且保证了也为逻辑的正确。

class Animal2 {
// 改进: 新增一个呼吸水的方法,这种方式虽然在类级别违反了单一职责原则,
// 但是在方法上遵循了。
// 注意: 单一职责原则在实际使用中,指的是遵循单一的业务逻辑。
public void breathe(String animal) {
System.out.println(animal + "呼吸空气");
} public void breatheWater(String animal) {
System.out.println(animal + "呼吸水");
}
}

单一职责的优点:

1.降低类的负责度,一个类只对一个业务逻辑负责;

2.提高项目的可读性,可维护性;

3.j降低项目变更的风险;

注意事项:

在项目中,我们应该尽量遵循单一职责原则,但是,当业务逻辑较简单时,可以违背。

DesignPattern系列__01SingletonResponsibility的更多相关文章

  1. DesignPattern系列__02接口隔离原则

    介绍 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小接口上. Demo引入 先来看一张图: interface MyInterface { void operation1(); ...

  2. DesignPattern系列__03依赖倒置原则

    依赖倒置原则(Dependence Inversion Priiciple,DIP) 介绍 High level modules should not depend upon low level mo ...

  3. DesignPattern系列__04里氏替换原则

    1.内容引入--继承体系的思考 在继承中,凡是在父类已经实现的方法,其实算是一种契约或者规范,子类不应该在进行更改(重写):但是,由于这一点不是强制要求,所以当子类进行重写的时候,就会对继承体系产生破 ...

  4. DesignPattern系列__05开闭原则

    介绍 开闭原则是编程设计中最基本.最重要的原则. 定义:一个软件实体如类.方法和模块等,应该对扩展(提供方)开放,对修改(使用方)关闭.用抽象构建框架,用实现扩展细节. 也就是说,在需求发生新的变化时 ...

  5. DesignPattern系列__06迪米特原则

    迪米特原则定义 迪米特原则,也叫最少知道原则,即一个类应该对自己依赖的类知道的越少越好,而你被依赖的类多么复杂,对我都没有关系.也就是说,对于别依赖的类来说,不管业务逻辑多么复杂,都应该尽量封装在类的 ...

  6. DesignPattern系列__10单例模式

    单例模式介绍 单例模式,是为了确保在整个软件体统中,某个类对象只有一个实例,并且该类通常会提供一个对外获取该实例的public方法(静态方法). 比如日志.数据库连接池等对象,通常需要且只需要一个实例 ...

  7. DesignPattern系列__09设计模式概述

    设计模式介绍 设计模式是程序员在面对同类软件工程设计问题所总结出来的有用的经验,模式不是代码,而是某类问题的通用解决方案, 设计模(Design pattern)代表了最佳的实践.这些解决方案是众多软 ...

  8. DesignPattern系列__08UML相关知识

    前言 现在,很少有人和90年代一样,自己去实现一个软件的各个方面,也就是说,在工作中,和人沟通是必备的技能.那么,作为一枚码农,如何和他人沟通呢?这就要依靠本文的主题了--UML. 简介 UML--U ...

  9. DesignPattern系列__07合成复用原则

    基本介绍 合成复用原则的核心,就是尽量去使用组合.聚合等方式,而不是使用继承. 核心思想 1.找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起. 2.针对接口编程,而不是 ...

随机推荐

  1. never下sqlcient

    [一]参数的输入 如执行update,我们写的代码应该是 sqlclient.Update(,, },@Name = "eee" }): 表示更新Id =1,2,3这三行的信息.这 ...

  2. SpringBoot系列——加载自定义配置文件

    前言 SpringBoot启动时默认加载bootstrap.properties或bootstrap.yml(这两个优先级最高).application.properties或application. ...

  3. IAR for STM8的简介、下载、安装及注册教程

    一.简介 1.关于IAR for STM8 IAR for STM8 是一个嵌入式工作平台,主要应用于STM8 系列芯片的开发,现在(2018年3.10版本)能够支持市面上所有的STM8芯片. 个人认 ...

  4. Dungeon Master POJ - 2251(bfs)

    对于3维的,可以用结构体来储存,详细见下列代码. 样例可以过,不过能不能ac还不知道,疑似poj炸了, #include<iostream> #include<cstdio> ...

  5. 并发编程-concurrent指南-ConcurrentMap

    ConcurrentMap 是个接口,你想要使用它的话就得使用它的实现类之一. ConcurrentMap,它是一个接口,是一个能够支持并发访问的java.util.map集合: 在原有java.ut ...

  6. Git 安装教程(2.21.0)

    获取安装包地址 1.官网(较慢):https://git-scm.com/downloads 2.下载链接:http://down-ww3.newasp.net/pcdown/soft/soft1/g ...

  7. HDU 3938:Portal(并查集+离线处理)

    http://acm.hdu.edu.cn/showproblem.php?pid=3938 Portal Problem Description   ZLGG found a magic theor ...

  8. Git 的一些使用细枝末节

    新入职XX公司第一天, 使用旧同事的电脑 Step1: 在Android Studio 中配置帐号 $ git config --global user.name author #将用户名设为auth ...

  9. JAVA面试题 启动线程是start()还是run()?为什么?

    面试官:请问启动线程是start()还是run()方法,能谈谈吗? 应聘者:start()方法 当用start()开始一个线程后,线程就进入就绪状态,使线程所代表的虚拟处理机处于可运行状态,这意味着它 ...

  10. Spring Cloud Alibaba | 序言

    目录 Spring Cloud Alibaba | 序言 1. Spring Cloud Alibaba是什么? 2. 主要功能 3. 组件 4. 版本说明 4.1 版本依赖关系 4.2 组件版本关系 ...