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

1.单一职责原则 单一职责原则:改变仅因为一个因素 <设计模式之禅>,作者提到有人写了个这样的接口 void changeUser(UserOB userOB,changeOptions option); 不如分开写 void changeUserName(String userName); void changeUserAddress(String address); void changeUserTel(String Tel); 虽然如作者提到的,下面的替代上面的,到底是不是应该替换呢?看

单一职责原则,从字面上理解就是做一件事情. 单一职责原则应用的场景包括: 一个接口只做同一类事情 一个类只做同一类事情 一个方法只做一件事情 一段代码只做一件事情 咱们具体分析各个应用场景吧 一.一段代码 ? 一段代码代表一种逻辑.代码是最细粒度,接口.类.方法都是由代码组成的. 二.一个方法 ? 如果方法中的代码逻辑比较简单,哪怕有分支,有不同的逻辑处理,那么也是允许的.如果方法中的代码逻辑很复杂,各种条件判断,如果以后需求发生变更,导致代码发生更改, 修改的时候必然会小心翼翼,生怕改的代码对

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:单一职责 书面理解 单一职责:就一个类而言,应该仅有一个引起它变化的原因 如果一个类承担职责过多,接等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制

职责过多坏处: 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力. 这种耦合会导致脆弱的设计,当变化发生是,设计会遭受到意想不到的破坏. 单一职责: 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 其实要去判断是否应该分离出类来,也不难,拿就是如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责的分离. 总结: 在类的职责分离上多思考,做到单一职责,这样你的代码才是真正的易维护,

大话设计模式第二章之:策略模式 算法之间可以互相调用 策略模式就是用来封装算法的. 大话设计模式第三章之:单一职责原则 单一职责原则:就一个类而言,应该仅有一个引起它变化的原因 类承担的职责不能过多,因为有时,完成一个职责,会影响到其他职责的, 手机只用来接电话,相机只用来拍照,功能才强大,集成太多了,其他功能就弱化了. 对应一些问题,要方法化,要类分离化 大话设计模式第四章之:开放-封闭原则 开放-封闭原则:是说软件实体(类.模块.函数等等)应该可以扩展,但是不可修改.OCP 扩展是开放的,修

单一职责原则:一个类,应仅有一个引起它变化的原因 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分享.如果你能够想到多于一个的动机去改变一个类,那么这个类就是具有多于一个的职责 学习大话设计模式03_单一职责原则

单一职责原则指的是就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能削弱或者抑制这个类完成其它职责的能力(就像一个程序员  叫他去做医学研究,生物研究,可能会抑制他学设计模式的能力).这种耦合会导致脆弱的设计,当变化发生时,设计会遭到异常不到的破坏(你医学研究久了,设计模式少接触,也就生疏了). 在写一个类的时候,要在类的职责分离上多思考(类的职责搞不清楚,就好像你生病了去找修车的,买菜去学校买),这样代码才是真正的可维护,易扩

单一职责原则(SRP):就一个类而言,应该仅有一个能引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 如果能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.就应该考虑类的职责分离.

单一职责原则(SRP),就一个类而言,应该仅有一个引起它的变化原因. 个人认为这个原则过于理想化,仅有一个并不是绝对的,合理就好. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离[ASD] 如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责. MVC,可以说良好运用了这个原则,但有时候一些小项目,可直接在service执行SQL语句,也是可以的. 开放-封闭原则,说是软件实体(类.模块.函数等等)应该可以扩张,但是不可修改. 对于扩张是开放的(Open for