重构 - Redistribution Responsibility
本文介绍了重构的第二大法宝:重新为类分配责任,简而言之,其包括:字段和函数的迁移、类的拆分和合并、委托隐藏和中间人移除、对于不可写类的功能扩展。在上一节着重介绍的函数拆分,包括各种临时变量的处理,对包括脚本和一般、严肃类型语言均适用。而本文介绍的方法,更多侧重 OOP 语言,最好是统一对象访问的语言,比如 Strongtalk(一种 Smalltalk 的方言)、Scala(一种 Java 的方言)、Dart(一种试图替代 TypeScript 的可选类型语言)。
在上一节中,我们将一个超大的函数拆分成了多个不同的部分,合理安置了临时变量,这在很大程度上已经很好的提升了程序的清晰性。但是还不够,当程序达到上万行的规模,一个超大的类包含超多的函数和一个超大的函数没有什么两样。因此,本节着重介绍对这种问题的处理,即根据类型来划分函数的归属的方法。
主要内容分为四个方面:
第一方面【类的组成】,对于多个类型,将其中不合适的方法、字段进行迁移,保证这些方法和其类型扮演的角色之间存在强相关,提高程序的清晰性。
第二方面【类的体量】,对于超大的单体类型进行拆分,或者对于多个类型进行合并,合理分配类型角色边界。
第三方面【类的权限】,对于类型和类型关系的处理,包括更加强力的控制访问字段类型,进行委托全局处理,或者放松限制,删除委托处理,允许客户直接访问对象。
第四方面【类的扩展】,对于无法修改的类型,添加功能的问题,解决方案之一是在客户端侧添加外部函数,解决方法之二是对原来的类进行包装、子类化,以保证在角色类似的前提下对功能进行扩展(面向修改关闭,面向扩展开放的设计原则)。
类的组成
Move Method
当一个类中的函数和别的类/被别的类更密切的使用,那么应该考虑将其移动到那个类中。如果有多个类使用,要么公共化,要么放在使用最多的类中,即 a.do(B b) 可以改成 b.do(A a)
。这样有助于提高类的功能边界的清晰性。
class A {
val a = 0
def doA(): Unit = { }
def doBInA(): Unit = {
doA()
println(a) //调用了 A 的字段和方法
//更接近 B 的责任
}
}
class B
Move Method 的要点在于确定此方法的依赖并且适当的进行处理:对于字段,更改为方法查询(或者不改,使用类.字段进行访问),对于方法,调用类.方法进行查询。
如上代码更改为:
class A2 {
val a = 0
def doA(): Unit = { }
def doBInA(): Unit = {
//如果不想影响别的依赖,直接委托 B 即可,否则,删除所有依赖
//此函数的方法
B2.doBInB(this)
}
}
object B2 {
def doBInB(a: A2): Unit = {
//对于 A 的调用,使用外部引用
a.doA()
println(a.a)
}
}
Move Field
对于字段而言,如果其面临和方法同样的问题,那么照例也要那样进行处理。
//Move Field
//要点:自我封装,确定一个统一引用点,然后委托其他类提供此字段
class A3 {
var a = 0
def method1InA(): Double = math.sqrt(a)
def method2InA(): Int = a * 10
}
class B3
需要注意的是,在原本类中可能有很多方法引用了字段,那么需要考虑先使用自我包装,将这个字段改变成一个方法查询,然后在方法查询入口提供一个委托入口。
对于 final 的字段而言,自我包装就没有必要了,直接在赋值的位置进行委托替换即可。这也适用于 Scala 的 val 变量。
class A4 {
//var _a = 0
def getA: Int = {
//_a Self Encapsulation Field 自我封装一般在 Move Field 中很有用
B4.a //当方法多次调用此字段,放在一个地方有利于统一管理
}
def method1InA(): Double = math.sqrt(getA)
def method2InA(): Int = getA * 10
}
object B4 {
var a = 0
}
这里需要注意的是,Move Field 和 Move Method 的区别是什么?在 Scala 下,Field 和 Method 是一个东西吗?不是,重构语境下的 Field 是一个值/引用,即便是函数,也是没有调用的函数。而 Method 是一个带有副作用的,依赖于类中其他字段、方法的动作。
因此,**这里的 Field 和 Method,是静态策略和动态方法之间的区别。因此,对于字段,要先升格为方法,然后在此方法中进行委托。**其实,这对于统一访问特性的语言来说是很容易理解的,在 scala 中,不存在对于字段的访问(编译成的 JVM 机器码再翻译为 Java 代码除外)。
这意味着,对于提供一个引用而言,做一个统一访问点,然后链接到其他类,委托实现,对提供一个对象而言,因为其可能依赖各种复杂的逻辑,因此需要提供其原本的对象(this),赋予移动函数后新函数内部访问原本类的一切公共资源,执行一个动作。
类的体量
因为平常使用 Scala 开发,下意识的,我总是会将函数中重复的部分提取为一个 val 变量,让这个变量表示一个函数,这就是上一节中讲到的基本函数拆分,如果此函数变量含有原本函数中间变量,则形成一个闭包,也就是上一节中讲到的解释性变量。因为这种思想,所以在处理类责任的时候,更多的会发现因为方法调用了很多的类变量,而觉得无法进行更细致的拆分了 —— 站在 FP 的角度,是的,无法将方法进一步拆分为不可变的算法和策略了。
但是这仅仅是对于 Move Field 和 Move Method 的不理解而已。Move Method 可以将过度耦合类变量的语句拆分出来,当方法仅访问某些只被其访问的变量的时候,这很容易拆分 —— 将它们塞入新类即可(Move Method),如果变量被原来类其余方法调用,只用更改调用为新类的变量即可(Move Field)。但是,如果一个方法访问类变量,更改类变量,并且调用了类的其他方法呢,这其实也很简单,Move Field 后,添加一个对于原本类的引用参数,让这部分的语句访问此类对象即可。类是类似于函数的一种作用域,仅仅是贴了一个做什么的标签,每个类不一定要是完全独立的,仅提供策略的,也可以是彼此紧密相连的,这对于习惯 FP 的开发者来说很难第一时间想到 —— FP 习惯了不可变的数据结构和类型。
下面介绍的拆分责任和合并责任中的拆分就需要迈过这个坎,如果理解到这个问题,那么对于一个和本类关系不密切,但是调用了大量的本类字段、方法的目标类而言,就很容易将其隔离,并且移动到新的地方:添加一个原本类的引用即可。
一个类应该表示一种抽象,但是实际开发中,常常为一个类添加过多的功能。这时候就应该提炼类 Extract Class。
一个很好的评价标准就是,如果子类化只影响了父类的某些特性,或者说,父类的某些特性需要用一种方式子类化,但是另外的一些特性需要以另一种方式子类化,这意味着需要分解原来的类。拆分原理和 Move Field、Move Method 类似。
和 Extract Class 相反的是 Inline Class,当一个类不再承担过多责任的时候,就删除这个类,使用方法和 Move Field、Move Method 类似。
拆分责任这件事,说着简单,但实际很难有一个客观的评价标准。尤其是对于 GUI 类而言,很容易写的过于庞大,因为中间涉及大量的 GUI 控件、控制方法和状态。因此,对于一个大类而言,要问自己,如果这个类要子类化成多个子类,即提供多个实现,那么要怎么做?这样想之后,如果做不到,那显然这个类扮演了过多的责任,因此考虑将其拆分,直到一个类能够明确责任边界(即你可以很轻松的想到它可以用 n 种不同的方法做)。对于有子类的类,如果各个子类之间存在较大的差异,那么也应该做这种考虑,各个子类应该仅仅是实现上的区别,和额外的功能补足,而不应该有不同的角色。
拆分类的一个实践
我试着对于 JavaFX 的一个 GUI 类进行拆分,之前它是合在一起的,即 GUI 组件和其 Controller 放在一起,虽然我也使用了几种重构手法拆分了大函数,并且创建了几个类分担这个 GUI 类的责任,这看起来很不错了。但是,那种拆分是基于功能的,我拆分的一个小的类包含一个清晰的责任边界,但是其中还是混杂了 GUI 组件以及其动态执行的方法。这种设计有典型的缺陷,就是耦合过度紧密,新类的 GUI 部分必须在原本类 GUI 初始化之前调用,但是新类的动态回调必须在原本类初始化之后由用户定义。这看起来还没什么,只是说新类必须在某个合适的地方初始化,在另外一个地方调用执行方法。
但是,当原本类越来越大,我不得不将其拆分为 Viewer 和 Controller,这是一种 MVP 的架构风格,其中 Viewer 和 Model 完全隔绝,不处理复杂逻辑,仅负责展现,并且提供几种可供 Controller 调用以改变外观状态的方法,而 Controller 则负责和 Model 逻辑交互。VC 的拆分就是一种对于类责任的划分,不同于之前的根据责任的划分,这种基于 VC 的划分更接近业界的划分标准,并且从长远的角度来看更有利于测试、集成和修改 —— 比如让 Viewer 重新实现为 Web、Swing 等。
同样的,我也对之前拆分的新类按照这样的方法拆分成了 Viewer 和 Controller,我发现,Viewer 如果要组合到别的组件上时,其 Controller 定义的回调必然没有设置。因为总是先创建 Viewer,因此,新类的 Controller 和原本类的 Controller 都必须延后调用,这是一种不太 FP 的方式。
原本类 Viewer -> 新类 Viewer -> 原本类 Controller -> 新类 Controller
。
这里还存在一个两个类的 Controller 的责任划分问题。具体而言,要尽可能保持一个清晰的责任边界,并且为未来的更改做出选择,即可以保持一个组件更抽象,而另一个组件完成脏活,这样,在下次重构时,只用处理其中之一即可。
此外,如果一个组件分成 Viewer 和 Controller,那么,对其扩展要如何处理呢?继承 Controller 或者 继承 Viewer,然后继承组件,为 Viewer/Controller 重新赋值是一种办法,其具体取决于实际想要重载的功能/外观。
拆分类的两种方式
这告诉我什么道理呢?拆分类,可能有约定俗成的业界标准,比如 MVC,或者其余领域设计模式 —— 抽象工厂等等。
拆分类不是一个简单的过程,因为我们不得不关注拆分后的类之间的关系,希望它们不要足够紧密,但是又可以不影响互相通信,同时满足可以扩展的需求。
一般而言,划分边界后,对于一个类很容易抽象出一个接口边界,这时候两个类交互使用接口即可。
此外,另一种做法就是子类化,这种方式更简单,子类有所有非私有父类字段方法读取权限,但是其实这是有条件的,因为子类通常是用来扩展满足相似功能的,子类和父类应该具有相同的功能范畴,因此,最好不要使用子类完成类的功能拆分 —— 当然,如果你发现类的一部分是善变的,那么将其拆分到子类进行实现,而在父类提供一个基础或者抽象方法(或者 Scala 的自身类型和特质混合)也是一种很好的实践。
这其实是委托和继承的选择,主要注意,在拆分类的时候,如果是功能拆分,那么使用接口和委托,如果是实现拆分,那么使用继承和子类。
类的权限
隐藏委托、合并责任
这个拆分纯粹是根据业务来的,在开发的不同阶段,可能需要进行不同的控制。这可能和访问对象的类字段对象的安全性、其字段多少、生命周期敏感性有关。
class Manager {
var player: Player = _
}
class Player {
var friend: Player = _
def doA(): Unit = {}
def doB(): Unit = {}
}
object Stage {
val manager: Manager = {
val t = new Manager
val player = new Player
val player2 = new Player
player.friend = player2
t.player = player; t
}
def main(args: Array[String]): Unit = {
manager.player.doA()
manager.player.friend.doB()
//移除中间人【Remove Middle Man】
//更灵活
manager
.player
.friend
.friend
.friend
.friend
.friend
.friend.doB()
}
}
拆分责任和移除中间人
当需要更加强力的控制,或者需要隐藏内部实现,更改为如下代码即可:
class Manager2 {
var player: Player2 = _
}
class Player2(private val friend: Player2) {
def doA(): Unit = {}
def doB(): Unit = {}
def callFriendsDoB(): Unit = {
if (friend != null) friend.doB()
}
def callFriendsFriendsFriendsFriendsFriendsDoB(): Unit = {
try {
friend.friend.friend.friend.friend.doB()
} catch {
case _: Throwable =>
}
}
}
object Stage2 {
val manager: Manager2 = {
val t = new Manager2
val friend = new Player2(null)
val player = new Player2(friend)
t.player = player; t
}
def main(args: Array[String]): Unit = {
manager.player.doA()
//封装后的结果 【Hide Delegate】
//更方便客户端调用
manager.player.callFriendsDoB()
manager.player.callFriendsFriendsFriendsFriendsFriendsDoB()
}
}
类的扩展
如果想要扩展类的方法,但是又因为各种原因不能修改类的话,可以使用对象技术和设计模式进行处理。
//当不可修改原本类时的方法扩展
class C(var init: Int = 0) {
def unitConvert(int: Int): Int = {
int * 100
}
def rateCompute(int: Int): Double = {
if (math.sqrt(int) > 200) 0.9 else 1.0
}
}
//假如需要大量计算 tateCompute(unitConvert(init)) * int
//这本应该假如到 C 中的,但是因为 C 无法更改,因此先放在客户端中
object CallC{
val c = new C(100)
val finalResult: C => Double =
c => c.rateCompute(c.unitConvert(c.init)) * c.init
//finalResult 就是外加函数,外加函数不能过多,否则还会造成混淆
//这时候应该使用 引入本地扩展 方法
def main(args: Array[String]): Unit = {
println(finalResult)
}
}
第一种方法是子类化,子类化是一种很好的分离代码的方式,在保持类型对象角色的一致性的情况下复用父类大部分代码,同时重写部分逻辑,改变部分行为,为原本的类提供多态能力以及扩展能力:
class SuperC(from:Int) extends C(from) {
def getFinalResult: Double =
this.rateCompute(this.unitConvert(this.init)) * this.init
}
object CallC2 {
val c = new SuperC(100)
def main(args: Array[String]): Unit = {
println(c.getFinalResult)
}
}
第二种方法是使用 Scala 的隐式类,它可以以一种神奇的方式为类提供扩展方法(动态底层包装和代理):
object CallC3 {
implicit class CExt(c:C) {
def getFinalResult: Double = c.rateCompute(c.unitConvert(c.init)) * c.init
}
val c = new C(100)
def main(args: Array[String]): Unit = {
println(c.getFinalResult)
}
}
————————
2019-05-05 撰写了本文
2019-05-06 添加了拆分类的一个实践和两种方式。