单一职责原则(SRP)->(以下括号里面的是自己的理解,其他的为摘抄)
准确的解释就是:对于一个类而言,应该仅有一个引起它变化的原因.
解决问题:实际开发中,如果一个类承担的职责过多,就等于是把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏.
(按我的理解就是:假如你在一个类里面写了过多东西,比如在一个Activity里面又要下载又要解析还要设置还要写Adapter,假如你Adapter又需要用到你的类里面其它地方的数据,可能你写的时候还很清晰,过上十天半个月回来一看,瞬间懵逼,改个需求牵一发动全身,这个时候你还能想起来你当时是怎么想的而保证只是一个两三分钟就可以解决的问题不用半个小时乃至更长时间吗?这里其实强调的是高内聚低耦合的思想)
当然,软件设计真正要做的许多内容,就是发现职责并且把那些职责相互分离,其实要去判断是否应该分离出来,也不难,就是如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,那么就应该考虑职责的分离.
(分离职责不是任何时候都要去做的,举个例子:现在的手机都有MP3,相机等很多功能,但是论专业MP3比不上专业音响,相机比不过单反,我们为什么还要把这些整合在一起呢?换个思路,假如MP3和单反都可以很方便携带也就不会有那么多问题了)
开放-封闭原则
概念:是说软件实体(类,模块,函数等等)应该是可以扩展的而不是可以修改的,总结为两个特征,一个是说"对于拓展是开放的(Open for extension)",另一个是说,"对于更改是封闭的(Close for modification)."
怎样的设计才能面对需求的改变却可以保持相对的稳定,从而使得系统可以在第一个版本以后不断推出新的版本呢?开放-封闭!!!
举例:公司规定早上九点必须到岗,不允许迟到,但是有几个公司骨干总是因为有事耽搁迟到,怎么解决?"严格执行考勤,迟到罚钱吗?" NO!大家之所以到不了肯定有不得已的苦衷,假如这样,人心肯定不齐."那么让有特殊情况的人打报告,允许迟到?" NO! 你问过那些不迟到的人吗?其实仔细想想,思考一下我们关注的是什么.
老板会在乎你迟到吗?答案是否定的,老板只关心你能不能工作够8个小时,确切的来说,老板关心的是你能不能完成业绩目标,这么一想,解决方法就很多了,比如弹性工作,每个月允许迟到几次,来得晚下班补,这其实就是对工作时间或者业绩成效的修给关闭(必须工作8小时或者必须达到什么业绩要求),对时间制度拓展的开放(修改上班时间这个接口,多提供几种方案).
这时你可能还有疑问,那么怎么才能保证绝对的对修改关闭呢?事实上,绝对的修改关闭是不可能的,无论模块多么的封闭,都会存在一些无法对之封闭的变化.既然不可能完全封闭,设计人员必须对于它设计的模块应该对哪种变化封闭做出选择.他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化,等到变化发生时立即采取行动,
在我们最初编写代码的时候,假设变化不会发生,当变化发生时,我们就创建抽象来隔离以后发生同样类型的变化,总而言之,面对需求,对程序的改动是通过增加新代码进行的,而不是修改现有的代码.(看起来可能有点儿绕,多看几遍慢慢理解吧,对自己说!)
下面还有几个概念:
并不是什么时候应对变化解决起来都是容易的,我们希望的是在开发工作展开不久的时候就能发现可能发生的变化,查明可能发生的变化所等待的时间越长,要创建正确的抽象就越困难.
最后,终于快敲完了,也到了核心了:
开放-封闭原则是面向对象的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可维护,可拓展,可复用,灵活性好.开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象,然而,对于应用程序中的每个部分都刻意的进行抽象同样不是一个好主意,拒绝不成熟的抽象和抽象本身同样重要,切记!切记!
