代码重构(五):继承关系重构规则

陆陆续续的发表了多篇关于重构的文章了,还是那句话,重构是一个项目迭代开发中必不可少的一个阶段。其实重构伴随着你的项目的整个阶段。在前几篇关于重构的文章中我们谈到了函数的重构、类的重构、数据的重构以及条件表达式的重构,那么今天咱们就来聊聊继承关系的重构。当然还是延续前几篇博客的风格,我们在博客中的代码实例依然使用Swift语言来实现,当然还是那句话,使用什么语言无所谓,关键是看重构的场景以及重构的思想。

“重构”不仅仅可以改善你既有的代码设计,还可以改变你组织代码的思路,使你的程序在设计之初就趋于合理化,利于程序的扩充。重构往往伴随着设计模式的使用,在重构系列的博客结束后,我想系统的给大家分享一下关于设计模式的东西。当然是结合着各种实例。所谓一名Coder,重构和设计模式是必须涉猎的部分,因为这两者可以让你写出更漂亮的代码,当然要想真正的掌握设计模式以及各种重构手法,还得结合不同的实例来进行实践。理论固然重要,但是要想将理论的东西变成你自己的,还必须将理论付诸实践。废话少说,进入今天的主题。

一.Pull Up Field (字段上移) & Pull Down Field (字段下移)

字段上移与字段下移是相对的,也是我们之前所说的“凡事都有其两面性”,我们要辩证的去看待。我们只对Pull Up Field (字段上移) 这个规则做讨论,那么关于Pull Down Field (字段下移)我们不做过多的讨论,因为这两条规则是相反的,理解一条后,把这条规则反过来就是我们要理解的另一条规则。这样说起来,还是比“举一反三”要容易的多。

下方这个实例是为了解释“字段上移”所实现的一个Demo。当然Demo看上去不仅简单而且是有些夸张的,不过说明字段上移这个规则是完全足够了的。比如我们有一个父类为MySuperClass,我们有一个子类SubClass1,而在SubClass1中有一个字段父类是没有的。因为后期需求迭代或者需求变更,我们需要再创建一个SubClass1的兄弟类,就是下方的SubClass2。在SubClass2中与SubClass1中存在相同的字段,那就是var a = 0。

    

 

 在上述情况下,就需要使用到我们的“字段上移”的规则。也就是说将子类中相同的字段移到父类中。在该实例中就是讲var a = 0 移到父类中。重构后的代码如下所示:

而将“Pull Down Field (字段下移)”正好与上面的情况相反。也就是父类中有某些字段,但是这些字段只有在少数子类中使用到,在这种情况下我们需要将这个字段移到相应的子类中即可。除了Pull Up Field (字段上移) & Pull Down Field (字段下移) 这两个规则外,Pull Up Method (将函数上移) 和 Pull Down Method (将函数下移)这两个规则与上述情况类似。就是将上面的字段改成函数,有时候不仅字段会出现上述情况,函数也会出现上述情况,需要我们进行移动。因为使用场景类似,再次就不做过多的赘述了。

 

二、Extract Subclass (提炼子类)

这种情况下用的还是比较多的,当类中的某些方法只有在特定的类的实例中才会使用到,此时我们就需要提炼出一个子类,将该方法放到相应的子类中。这样一来我们的每个类的职责更为单一,这也就是我们常说的“单一职责”。

在下方示例中,CustomerBook是一个图书消费者的类。其中customeCharge()方法是普通用户计算消费金额所需的方法,而vipCharge()方法是VIP用户调用的方法,在内部vipCharge()需要调用customeCharege()方法。但是对外部而言,vipCharge()方法只有VIP用户才会用到,在这种情况下我们就需要使用“Extract Subclass (提炼子类)”规则对VIP进行提炼。

    

 

具体做法是我们需要提炼出一个子类,也就是说将VIP用户作为普通用户的子类,然后将只有VIP用户才调用的方法放到我们的VIP子类中。这样一来层次更加明确,每个类的职责更为单一。上述示例重构后的结果如下所示。

   

与“提炼子类”规则相对应的是“Collapse Hierarchy (折叠继承关系)”。一句话来概括:就是当你的父类与子类差别不大时,我们就可以将子类与父类进行合并。将上面的示例翻转就是“Collapse Hierarchy (折叠继承关系)”规则的示例,再次就不做过多的赘述了。

 

三、Form Template Method (构造模板函数)

Form Template Method (构造模板函数)这一规则还是比较实用的。先说模板,“模板”其实就是框架,没有具体的实现细节,只有固定不变的步骤,可以说模板不关心具体的细节。举个栗子,像前段时间比较火的“秘密花园”,那些没有颜色的线条就是模板,如果一些人获取的是同一本秘密花园,那么说明每个人所获取的模板是相同的。但是每个人对每块的区域所图的颜色又有差异,这就是实现细节的不同。

言归正传,当两个兄弟类中的两个函数中的实现步骤大致一直,但是具体细节不同。在这种情况下,我们就可以将大体的步骤提取成模板,放到父类中,而具体细节由各自的子类来实现。具体实现请看下方的类,在Subclass1和Subclass2中的calculate()方法中的大体步骤是相同的,就是对两个值相加,然后返回这两个值的和。但是具体细节不同,可以看出两个相加值的具体计算方式不同。

  

 

在上述情况下我们就可以使用“Form Template Method (构造模板函数)”规则将相同的计算流程进行提取,也就是构造我们的模板函数。将模板函数放到两个类的父类中,然后在相应的子类中只给出实现细节即可。下方代码段是重构后的代码,父类中多出的方法就是我们提取的模板函数,而子类中只给出相应的实现细节即可。

  

 

四、以委托取代继承(Replace Inheritance with Delegation)

有时候我们为一些类创建子类后,发现子类只使用了父类的部分方法,而且没有继承或者部分继承了父类的数据。在这种情况下我们就可以将这种继承关系修改成委托的关系。具体做法就是修改这种继承关系,在原有子类中添加父类的对象字段,在子类中创建相应的方法,在方法中使用委托对象来调用原始父类中相应的方法。

下方示例是我们假想出来的,但是说明该规则是绰绰有余了。我们假设SubClass01类中只会用到SuperClass01中的display()方法,而没有继承父类中的数据。在下方示例中是继承关系,在这种情况下我们需要将其转换成委托关系。

  

下方是我们重构后的代码,在下方代码中我们去除了之前的继承关系。并在子类中创建了一个之前父类的代理对象,并且创建了一个相应的方法,在该新建的方法中通过代理对象来调用相应的方法。具体如下所示。

  

上述规则与以继承取代委托(Replace Delegation with Inheritance)原则相对于,使用情况与上述相反,再次就不做过多的赘述了。

几天博客就先到这儿,内容比较简单,但是还是比较重要的。

时间: 2024-11-03 11:45:08

代码重构(五):继承关系重构规则的相关文章

代码重构(三):数据重构规则

在<代码重构(一):函数重构规则(Swift版)>和<代码重构(二):类重构规则(Swift版)>中详细的介绍了函数与类的重构规则.本篇博客延续之前博客的风格,分享一下在Swift语言中是如何对数据进行重构的.对数据重构是很有必要的,因为我们的程序主要是对数据进行处理.如果你的业务逻辑非常复杂,那么对数据进行合理的处理是很有必要的.对数据的组织形式以及操作进行重构,提高了代码的可维护性以及可扩展性. 与函数重构与类重构类似,对数据结构的重构也是有一定的规则的.通过这些规则可以使你更

代码重构(二):类重构规则

在上篇博客<代码重构(一):函数重构规则(Swift版)>中,详细的介绍了函数的重构规则,其中主要包括:Extract Method, Inline Method, Inline Temp, Replace Temp with Query, Introduce Explaining Variable, Split Temporary Variable, Remove Assignments to Parameters, Replace Method with Method Object等.关于

代码重构(一):函数重构规则

重构是项目做到一定程度后必然要做的事情.代码重构,可以改善既有的代码设计,增强既有工程的可扩充.可维护性.随着项目需求的不断迭代,需求的不断更新,我们在项目中所写的代码也在时时刻刻的在变化之中.在一次新的需求中,你添加了某些功能模块,但这些功能模块有可能在下一次需求中不在适用.或者你因为需求迭代与变更,使你原有的方法或者类变得臃肿,以及各个模块或者层次之间耦合度增加.此时,你要考虑重构了.   重构,在<重构,改善既有代码的设计>这本经典的书中给出了定义,大概就是:在不改变代码对外的表现的情况

实例解析继承体系重构及ORM映射

本文以双鱼座同学的再说继承关系一文中提到的一组三元继承关联关系为基础. 首先,分别实现本人的ORM中的继承关系映射全解一文中提到的三种实体继承体系到关系数据库的映射方案实例. 接着,使用接口分离以上继承体系中的实体类中的相同概念,对该继承体系进行重构,并同样给出对重构后的继承体系的三种到关系数据库的映射方案实例. 全部实例代码基于NBear的接口式实体定义方式实现. 1. 背景 首先,给出双鱼座同学原文中的三元继承关联关系的等价接口定义.见下图1: 2. 对图1-1的ORM映射 2.1 单表继承

浅谈UML中类之间的五种关系及其在代码中的表现形式

本文转载:http://www.cnblogs.com/DebugLZQ/archive/2013/05/13/3066715.html 什么是类? 将某类东西归纳在一起,可以成为一个类. 类有很多种提炼角度,需要根据系统地目标.业务的场景,选取合适的角度对事物进行归纳. 什么是类图? 类图可能是UML中使用的最多的一种图. 和其他图一样,类图的基本语法并不复杂,可能一两天就能掌握,但是真正做到灵活的使用类图,可能需呀多年的功力. 类图是锻炼OOA(OO Analysis)和OOD(OO Des

Active Record学习笔记(五):处理继承关系

本文主要介绍了如何使用Castle.ActiveRecord来处理继承关系. 本文涉及两个实体类:基类(User).子类(Employee).以下是类图: 本文主要内容: 1.编写数据库脚本 2.JoinedBase和JoinedKey属性说明 3.编写实体类 4.编写调用代码 一.编写数据库脚本 其实本文涉及的数据表在前面的笔记中都出现过! Create Table Users ( ID int identity(1,1) primary key, LoginName Varchar(50)

《重构—改善既有代码设计》——第二章重构原则——学习笔记

1:什么是重构? 重构是一个过程:在不改变代码外在行为的前提下,对代码做出修改,以改进程序内部结构.本质上说,重构就是[在代码写好之后改进它的设计]   2:为什么要对项目进行重构呢?重构对软件开发有什么好处,   为什么要重构呢,打个贴切的比方:我平时比较 懒散,屋子里面的东西都是随手乱放,时间长了,屋子里面就乱七八糟了.有时候到了自己也忍无可忍的时候,我就要大动干戈了,把该放哪儿的东西都整理到哪 儿,该扔掉的东西全部扔掉.一个项目也是如此,有时候可能是设计不到位:有时候可能是经过多人的修改,

改善代码设计 —— 处理概括关系(Dealing with Generalization)

系列博客       1. 改善代码设计 -- 优化函数的构成(Composing Methods)       2. 改善代码设计 -- 优化物件之间的特性(Moving Features Between Objects)       3. 改善代码设计 -- 组织好你的数据(Composing Data)       4. 改善代码设计 -- 简化条件表达式(Simplifying Conditional Expressions)       5. 改善代码设计 -- 简化函数调用(Maki

一起谈.NET技术,改善代码设计 —— 处理概括关系(Dealing with Generalization)

系列博客       1. 改善代码设计 -- 优化函数的构成(Composing Methods)       2. 改善代码设计 -- 优化物件之间的特性(Moving Features Between Objects)       3. 改善代码设计 -- 组织好你的数据(Composing Data)       4. 改善代码设计 -- 简化条件表达式(Simplifying Conditional Expressions)       5. 改善代码设计 -- 简化函数调用(Maki