
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了软件开发设计模式的一些常见类型等内容,而本文我们就再来了解一下,软件开发设计模式中单一职责原则应用。
1、单一职责定义
单一职责原则:一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。
单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责
变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。
2、单一职责优点
1)降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。
2)提高了代码的可读性。一个类简单了,可读性自然就提高了。
3)提高了系统的可维护性。代码的可读性高了,并且修改一项职责对其他职责影响降低了,可维护性自然就提高了。
4)变更引起的风险变低了。单一职责大的优点就是修改一个功能,对其他功能的影响显著降低。
3、自己理解
单一职责原则有两个难点:
1)职责划分:
一个职责一个接口,但问题是“职责”是一个没有量化的标准,一个类到底要负责那些职责?这些职责该怎么细化?细化后是否都要有一个接口或类?这些都需要从实际的项目去考虑。
比如上面写成一个类他的单一职责就是修改用户信息,为什么一定要分修改行为和修改属性。那是不是又可以在细分修改密码和修改属性呢?
2)类的冗余
如果可以追求单一职责也是没有必要的,本来一个类可以搞定的实现,如果非得修改用户名一个类,修改密码一个类来实现单一原则,这样也会让你的类变得非常多,反而不容易维护。
4、我自己的感悟:
1)先要培养单一职责的思想,特别是如果代码可以复用的情况下经常思考能不能用单一职责原则来划分类。
2)类的单一职责实现在好多时候并不切实际,但是方法上一定要保持单一职责原则。比如你修改密码的方法就是用来修改密码。这样做有个很大的好处就是便于代码调试,容易将代码的Bug找出来,一个方法只完成
一件事情,相对调试能简单很多,让其他人员能更快更好的读懂代码、理解这个类或者方法的功能。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。