单一职责

小菜学设计模式——单一职责原则

别说谁变了你拦得住时间么 提交于 2020-12-04 07:37:16
背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习《大话设计模式》时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习 设计模式的 成长之旅。 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:单一职责 书面理解 单一职责:就一个类而言,应该仅有一个引起它变化的原因 如果一个类承担职责过多,接等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化放生时,设计会遭受到意想不到的破坏。 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。判断是否应该分离的标准是:如果你能够想到多于一个的动机去改变一个类,那么这个类具有多于一个的职责。 个人的理解 假设一件衣服是上班的正装,那么请不要在聚会的时候使用;如果是聚会时使用的休闲礼服,请不要穿着去上班。正装的唯一职责就是上班时穿,礼服的唯一职责就是聚会时穿。如果二者混在一起,假设你穿着正装去参加聚会,那么聚会上很可能需要打扮、修饰一下自己的衣服,那么会尽量把正装的风格往休闲的角度去整改,整改成功之后,可以参加聚会了,但是这件衣服似乎会已经影响到了下次上班穿。 单一职责:不是一个类只做一件事情,而是类(属性以及操作属性的方法