https://mp.weixin.qq.com/s?__biz=MzUyNDkzNzczNQ==&mid=2247489488&idx=2&sn=a3fce7d1ac1a78566de2f1658366f75f&chksm=fa24e8b8cd5361ae7db6aed54438fca62bfdfd9e10ffd48fcaff12d881a603890e06753a1a98&scene=0&xtrack=1#rd
阅读本文大概需要 5 分钟。
来自:https://urlify.cn/6jQRN3
最近,在对已有项目进行扩展的时候,发现要改动的一个类它长900行,开放了近40个public接口,我流着泪把它给改完了。为了防止这样的惨剧再次发生在我的身上,我觉得有必要写一篇博客来让广大程序猿同胞知道代码重构的重要性。如果你身边有一个类写上千行的猿,一定要把此文转给ta读不通——直接用滚轮滚都得好几秒,就算是原作者,时间长了恐怕也难以理清整个类,更不用说是其他的读者
扩展不通——一个类有过多的接口,会让扩展这个类变得异常困难,一动千行
冗余代码使方法、类过长,不简洁
冗余代码会造成发散式修改(冗余代码需要变动时,每一处Ctrl+V都需要修改)
违反设计原则——单一职责原则(单一职责原则要求一个类只实现一个职责,比如一只Tom只做扫地、擦桌、拖地中的一件事,而其他事的实现可以转移给史派克狗或肥胖女佣),违反了这个原则会导致发散式变化、发散式修改、类过长等代码问题,还会让你的类难以扩展,甚至会让其他程序猿认为你不专业
发散式变化(指引发此类修改的地方很多),如果一个类的职责很多,那它的扇入(调用者)一定很多,每个调用者的修改都有可能让你这个类不得不随之修改,也就是发散式变化
话外音:就是说不管哪儿出了问题,你这个类都得遭殃
发散式修改(指此类修改引发修改的地方很多),相同的,如果一个类职责很多,那支撑它实现的下级,即扇出(被调用方)一定很多,如果此类逻辑发生变动,所有下级被调用者可能都得随之修改,也就是发散式修改
话外音:就是说你这个类出了问题,不管哪儿都会遭殃
难以扩展:如果你的一个类接口非常多,那它的子类怎么办?它的包装类怎么办?难道全部都要实现这么多接口,全部都要承担同样多的职责吗?扩展起来真的非常麻烦
触发机关:【测试之怒】【运维之怒】
注意:方法的名字指的是方法做了什么,而非怎么去做,最好是 动词+名词 格式比如:Tom.扫地() √Tom.扫地With扫把() ×Tom.用扫把扫地() ×
图中成员【偏A】被类【A】调用两次,而只被它所在的类【过长类】调用1次,因而应该转移给【A】去管理
由于函数【偏A】与成员【偏A】的亲密度较高(只调用了【偏A】),因而应与【偏A】共进退,同去留,转移给【A】
成员【偏B】和函数【偏B】也是相同道理
职责1(函数【1】和成员【偏职责1】)和职责2(函数【2】和成员【偏职责2】)由于找不到可转移的合适的类,所以应抽取出一个新的类
注意,先决定移动哪个成员变量,然后再决定移动哪个函数
移动成员变量,鼠标选择成员变量->右键->Refactor->Move,然后选择转移至哪个类
移动函数(与移动成员变量步骤相同)
不推荐抽取参数对象,因为一般参数对象是给参数多的方法用的(用参数对象取代一长溜的参数),而且如果成员变量抽取了也不会影响任何函数的话,那就是无用对象了,不如直接把他们删除掉2.为新类起个名,选个包吧3.注意,抽取的函数和成员一定要符合一个原则,那就是被抽取函数使用被抽取成员的次数一定高于剩余函数的次数,不然违反亲密性原则(成员应归于调用它最多的类,没有理由你用的比我多还让我来管理)4.一些小问题由于抽取的函数直接使用了未抽取的对象而导致重构失败,涉及到另一个重构(使用get方法而非直接使用私有成员变量),使用此重构即可解决
<END>
推荐阅读:
痛心!Pandownload开发者被抓!我终于决定使用Docker搭建一个多端同步网盘!
5T技术资源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,单片机,树莓派,等等。在公众号内回复「2048」,即可免费获取!!
原文:https://www.cnblogs.com/Limer98/p/12816900.html