大话设计模式杂谈（3）单一职责原则

单一职责原则      就每一个类而言，应该仅有一个引起它变化的原因      如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏      软件设计真正要做的许多内容，就是发现职责并把那些权职相互分离，其实要去判断是否应该分离出类来，也不难，就是如果你能够想到多...

单一职责原则：一个类应该仅有一个引起它变化的原因。软件设计需要做到职责相互分离。        如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱这个类完成其他职责的能力，牵一发而动全身。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。        单一职责的代码更容易维护和拓展。

《大话设计模式》之讲解单一职责原则，讲的通俗易懂，做笔记记录如下。以下主要文字均摘录自《大话设计模式》一书，感谢作者程杰！ “单一职责原则，意思就是说，功能要单一？ 可以简单的这么理解，它的准确解释是：就一个类而言，应该仅有一个引起它变化的原因。我们在做编程的时候，很自然的会给一个类各种各样的功能，比如我们写一个窗体应用程序，一般都会生产一个form这样的类，于是我们把各种各样的代码，想商业运算

大话设计模式之设计原则

以下列表中的计算机书籍（中文版）来自微博：@程序员的那些事 粉丝的推荐。按推荐次数，从高到低往下排。如果大家还有其他计算机相关的经典书籍推荐，请在评论中留言，或者在这条微博的评论中留言，我们将继续扩充这个列表。 1.算法导论（第2版） 2.代码大全（第2版） 3.C++ Primer中文版（第4版） 4.设计模式：可复用面向对象软件的基础 5.浪潮之巅 6.Java编程思想（第4版）

3个月之前，来到现在的公司。     入职第一天，去沈阳出差。这一去就是40天。想起之前同事们在各个朋友圈发的出差照，旅游照。小编突然觉得幸福来得太突然了。轮到小编开始嘚瑟的日子终于到了。没想到40天之后，小编可以嘚瑟的竟然 这是我最累最累的一次经历了~40多天 再6台空调的服务器屋里，冻得小伙伴大伙伴们甚至连酒店的床单浴巾都拿来御寒了。基本是天天加班，只休息过一天。再想想入职第一天组长跟大家介

　　一晃，一个年头又过去了。 　　历时，入门互联网行业已然三年之多。从一个 hello word 开始一直磨练至今，宝刀未见锋锐(好像有点飘，程序员不应该这样的...)。 如下列举近几年经手或常听说的软件。 企业级应用软件： 1.常规行业软件如OA/ERP/CRM等，模式相对已经成熟，技术层实现模块需求即可，大同小异。 2.特定行业软件如多商户管理系统/物业软件系统/金融类软件...

1.首先讲一下为什么开始写博客 在原来一直学习的过程中，主要以有道云笔记来记录一些自己学习过程的知识点，但写过了从来没有回顾过，写完了就是写完了，可能这样的意义并不是很大，但是以写博客的形式分享出去，只有别人看懂了，那才真正的说明你会了，所以让别人看懂，学会也是一件很困难的事情。 我现在是一名Java工程师，但我的梦想并不是成为一名很牛的技术大佬，我的梦想是成为一名老师，因为我喜欢教育给我带来的成...

定个目标： 2017年需要看完的15本书 基础回顾类： 1.第一行代码 2.android高薪之路-android程序员面试宝典 3.head of java 技能提升类： 4.android，从小工到专家 5.android开发艺术探索 6.重构-改善既有代码的设计 7.大话设计模式 其他拓展类： 8.android移动开发网站详解 9.php程序设计 10.javaw

今天闲来没事，统计下自己持有和购买的书籍分享下！ １．嵌入式硬件设计（还没看完）感觉有电泛了！ ２．Java开发实战经典（当初买的时候有点冲动，不是我想要的Java入门书籍） ３．Java编程思想（经典书籍还没看多少不过会好好完全消化的） ４．Java核心技术１ （ｓｕｎ公司核心技术丛书之一很不错讲的很好） ５．Java核心技术２（ｓｕｎ公司核心技术丛书之一上下两册） ６．爪珪夜未眠－...

英语:飙升的好方法 (转载自 茵茵向荣) 程序员第二定律：量化管理在程序员身上永无可能 软件项目质量保证——编码规范 75道逻辑推理题及答案 第1章 计算机网络概述 第2章 传输媒体 第3章 以太网 计算机网络笔记四 无线局域网 软件项目“免坑”指南 敏捷个人-阅读笔记 现代软件工程讲义 9 测试 QA 的角色和分工 我们需要顶层设计 软件工程师的视角看网络（网络那点事)

很高兴又在每天的这个时间和大家一起分享自己的学习见解,今天我看了一下大话设计模式里面的单一职责原则，现在就跟大家一起分享一下自己的学习成果： 单一职责的定义: 就一个类而言,应该只有一个引起它变化的原因。 为什么要使用单一职责模式呢： 如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱或者抑制这个类完成他职责的能力。这种耦合会导致脆弱的设计，设计会遭到意想不...

问题由来  问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。  解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。  但是即便是经验丰富的程序员写出的程序

转载之【大话设计模式】

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

1：单一职责原则（SRP）,就一个类而言，应该仅有一个引起它变化的原因 2：如果一个类承担责任过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到破坏[ASD] 3: 软件设计真正要做的许多内容，就是发现职责并将这些职责分离[ASD],如果你能够想到多余一个动机去改变一个类，那么这个类就具有多余一

设计模式六大原则 定义：单一职责原则又称单一功能原则，它规定一个类或模块应该有一个单一的功能，并且一个功能应该完全由一个类或模块封装起来。 直接举例子： 从网络上请求下来数据，然后储存到本地数据库中，整个需求下来应该是这样的： 这里网络请求模块，里面1.根据url返回json数据，2.解析json数据，3.储存到本地数据库。 这样做的问题： 1.逻辑上耦合度太高，无论是修改网络请求、Jso...

单一职责原则

什么是单一原则： 就一个类而言，应该仅有一个引起它变化的原因，通俗的说，就是一个类只负责一项职责。 问题由来： 类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，，由于类T承担的职责有多个（p1,p2），职责P1的变化有可能会导致原本运行正常的职责P2功能发生故障。 解决方案： 遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1...