快速理解-SOLID-面向对象设计单一职责原则

快速理解 SOLID (面向对象设计)——单一职责原则在程序设计领域, SOLID(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转),指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时,它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。1. 单一职责原则1.1 单一职责原则 的定义不要存在多于一个导致类变更的原因。简单的讲,认为对象应该仅具有一种单一功能。 1.2 单一职责原则 解决了什么问题类A 负责两个职责P1、职责P2。当由于职责P1需求发生改变时,而需要在类A中修改职责P1。有可能使原本正常运行的职责P2发生故障。 1.3 单一职责原则 举个例子//不符合 单一职责原则public class UserService { // ...增加 User 功能 // ...删除 User 功能 // ...更新 User 功能 // ...查询 User 功能 // ...User 登录功能}上面这个UserService类可以看作有两个职责: 对 User 数据的操作。对 User 验证。根据单一职责原则应该将这两个职责分别放在两个类中: //符合 单一职责原则public class UserDataService { // ...增加 User 功能 // ...删除 User 功能 // ...更新 User 功能 // ...查询 User 功能}public class UserAuthService { // ...User 登录功能}1.4 单一职责原则 的优点降低类的复杂度,一个类只负责一种职责。提高代码的可读性。降低更改需求带来的风险,降低对其他功能的影响。2. 关注我的微信公众号,查看更多文章,第一时间收到我的文章。 ...

September 8, 2019 · 1 min · jiezi

单一职责原则

个人博客原文:单一职责原则设计模式六大原则之一:单一职责原则简介姓名 :单一职责原则英文名 :Single Responsibility Principle座右铭 :There should never be more than one reason for a class to change. 应当有且仅有一个原因引起类的变更。。。意思就是不管干啥,我都只干一件事,你叫我去买菜,我就只买菜,叫我顺便去倒垃圾就不干了,就这么拽脾气 :一个字“拽”,两个字“特拽“伴侣 :老子职责单一,哪来的伴侣?个人介绍 :在这个人兼多责的社会里,我显得那么的特立独行,殊不知,现在社会上发生的很多事情都是因为没有处理好职责导致的,比如,经常有些父母带着小孩,一边玩手机,导致小孩弄丢、发生事故等等单一职责应用范围单一职责原则适用的范围有接口、方法、类。按大家的说法,接口和方法必须保证单一职责,类就不必保证,只要符合业务就行。方法设想一下这个场景:假设我们要做一个用户修改名字以及修改密码的功能,可以有多种实现方案,比如下面列举 2 种实现方式代码:SrpOfMethod.java第一种实现方式/** * 错误的示范 /enum OprType { /* * 更新密码 / UPDATE_PASSWORD, /* * 更新名字 / UPDATE_NAME;}interface UserOpr { boolean updateUserInfo(User user, OprType oprType);}class UserOprImpl implements UserOpr { @Override public boolean updateUserInfo(User user, OprType oprType) { if (oprType == OprType.UPDATE_NAME) { // update name } else if (oprType == OprType.UPDATE_PASSWORD) { // update password } return true; }}第二种实现方式/* * 正确的示范 /interface UserOpr2 { boolean updatePassword(User user, String password); boolean updateUserInfo(User user);}class UserOprImpl2 implements UserOpr2 { @Override public boolean updatePassword(User user, String password) { user.setPassword(password); // update password return true; } @Override public boolean updateUserInfo(User user) { // update user info return true; }}2 种实现有什么区别呢? 第一种实现通过 OprType 类型的不同来做不同的事情,把修改密码和修改名字耦合在一起,容易引起问题,只要稍不注意,传错枚举值就悲剧了,在代码中也没法很直接看到是做什么操作,也就是这个方法的职责不明确。而第二种实现,把修改密码和修改名字分离开来,也就是把修改密码和修改名字都当做独自的职责处理,这样子就很清晰明了,你调用哪个方法,就很明确的知道这个方法是实现什么逻辑。结论是啥呢?用第二种方式实习才符合单一职责原则。现实中看到很多像第一种实现的代码,而且是枚举有十来个的情况,看代码真费劲。接口设想一下这个场景,假设我们让小明去倒垃圾,小红去买菜,小红回来后再叫小红去洗碗。下面也举 2 个实现的例子。代码:SrpOfInterface.java第一种实现方式/* * 错误的示范 /interface Housework { void shopping(); void pourGarbage();}class XiaoMing implements Housework { @Override public void shopping() { // 不购物 } @Override public void pourGarbage() { System.out.println(“pourGarbage …”); }}class XiaoHong implements Housework { @Override public void shopping() { System.out.println(“shopping …”); } @Override public void pourGarbage() { // 从不倒垃圾 }}中途回来小红去洗碗,要怎么实现?按这个写法,就在 Housework 接口添加 washingUp() 方法,然后小明和小红依次都实现洗碗这个方法,只是小明不做具体实现代码,这样子是不是觉得很别扭,不符合单一职责原则的,修改一个地方,不影响其他不需要改变的地方,只对需要用到的地方做修改。小明本来就不用洗碗,却要去实现洗碗这个方法。第二种实现方式/* * 正确的示范 */interface Shopping { void doShopping();}interface PourGarbage { void doPourGarbage();}interface WashingUp { void doWashingUp();}class XiaoMing2 implements PourGarbage { @Override public void doPourGarbage() { System.out.println(“pourGarbage …”); }}class XiaoHong2 implements Shopping, WashingUp { @Override public void doShopping() { System.out.println(“shopping …”); } @Override public void doWashingUp() { System.out.println(“washing up …”); }}可以看到,这种实现把不同的家务都当做不同的职责,分离开来,这种实现可以按需实现做家务的类型,小明只需要去倒垃圾,就实现 PourGarbage 接口,小红去购物和洗碗,就实现 Shopping 和 WashingUp 接口,完全不会影响到对方,这才是完美的根据单一职责原则编写出来的代码。类类这个看了一些资料都说没法硬性要求一定按单一职责原则分,或者说类的职责可大可小,没有很明确的像上面接口那样按照单一职责原则分就很清晰也很有道理。设想一下这个场景:我们要实现一个用户注册、登录、注销操作,可以像如下 2 种实现方式代码:SrpOfClass.java第一种实现方式从用户的角度考虑,这些操作都是用户的行为,可以放在一个统一的类 UserBizclass UserBiz { public boolean register(User user){ // 注册操作 return true; } public boolean login(User user) { // 登录操作 return true; } public boolean logout(User user) { // 注销操作 return true; }}第二种实现方式有人又说,不是说单一职责么?从业务操作考虑,需要把注册、登录、注销分开class UserRegisterBiz { public boolean register(User user){ // 注册操作 return true; }}class UserLoginBiz { public boolean login(User user) { // 登录操作 return true; }}class UserLogoutBiz { public boolean logout(User user) { // 注销操作 return true; }}感觉像是在抬杠,其实这个没有好坏之分,根据具体业务具体分析,你说你的登录、注册、注销操作代码很多,需要分开,那就分开,无可厚非。好处类的复杂性降低,实现什么职责都有清晰明确的定义可读性提高,复杂性降低,那当然可读性提高了可维护性提高,可读性提高,那当然更容易维护了变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助(来自《设计模式之禅》)总结这个单一职责原则,目的就是提高代码的可维护性、可读性、扩展性,如果为了单一职责而破坏了这 3 个特性,可能会得不偿失。参考资料:《大话设计模式》、《Java设计模式》、《设计模式之禅》、《研磨设计模式》、《Head First 设计模式》 ...

December 27, 2018 · 2 min · jiezi