重构改善既有代码的设计-学习(一):封装

发布时间:2024年01月20日

1、封装记录(Encapsulate Record

?

? ? ? ? 一些记录性结构(例如hash、map、hashmap、dictionary等),一条记录上持有什么字段往往不够直观。如果其使用范围比较宽,这个问题往往会造成许多困扰。所以,记录性结构应该被封装成为一个类。

? ? ? ? 例如:

organization = {name: "Acme Gooseberries", country: "GB"};

? ? ? ? 应该被重构为:

class Organization {
    constructor(data) {
        this._name = data.name;
        this._country = data.country;
    }
    get name() {return this._name;}
    set name(arg) {this._name = arg;}
    get country() {return this._country;}
    set country(arg) {this._country = arg;}
}

?2、封装集合(Encapsulate Collection)

?

????????我们通常鼓励封装,但封装时人们常常犯一个 错误:只对集合变量的访问进行了封装,但依然让取值函数 返回集合本身。这使得集合的成员变量可以直接被修改,而封装它的类则全然不知,无法介入。

? ? ? ? 修改的方式是,在类上提供一些修改集合的方法(通常是“添加”、“删除”等),这样就可以使对集合的修改必须经过类。

? ? ? ? 例如:

class Person {
    get courses() {
        //这里直接把对象本身返回了,在哪里偷偷摸摸被改了都不知道
        return this._courses;
    }  
    set courses(aList) {this._courses = aList;} 
}

? ? ? ? 应该改为:

class Person {
    get courses() {return this._courses.slice();}

    // 提供修改对象的方法,想改,就必须用类的方法
    addCourse(aCourse) { ... }
    removeCourse(aCourse) { ... }
}

3、以对象取代基本类型(Replace Primitive with Object)

?

? ? ? ? 不要执着于用基本类型,应该把一些数据封装成对象。

? ? ? ? 例如,本身“图案”这个字段可能只是一个字符串,用来存储一个链接,但后来随着业务的逐渐复杂,开始有尺寸、文案等等,那他们就应该被抽取出来,放在一个类里面。

4、以查询取代临时变量(Replace Temp with Query)

?

? ? ? ? 如果一个变量只声明一次之后不再被改变,那就别再声明变量了,而是直接用一个查询操作取代他。比如:

// 这里的变量只用了一次
const basePrice = this._quantity * this._itemPrice;

if (basePrice > 1000)
    return basePrice * 0.95;
else
    return basePrice * 0.98;

? ? ? ? 应该变为?:

// 构建一个查询用来替代那个变量
get basePrice() {this._quantity * this._itemPrice;}

...

if (this.basePrice > 1000)
    return this.basePrice * 0.95;
else
    return this.basePrice * 0.98;

?5、提炼类(Extract Class)

????????在实际工作中, 类会不断成长扩展。设想你有一个维护大量函数和数据的类。这样的类往往 因为太大而不易理解。此时你需要考虑哪些部分可以分离出 去,并将它们分离到一个独立的类中。如果某些数据和某些 函数总是一起出现,某些数据经常同时变化甚至彼此相依, 这就表示你应该将它们分离出去。

6、内联类(Inline Class)

?

? ? ? ? 当一个类因为某种原因开始萎缩(可能是因为一些重构动作移走了这个类的责任),不再承担足够责任,那么他不再有单独存在的理由。应该将“萎缩类”塞进另一个类中。“另一个类”应该是和“萎缩类”关联最紧密的那个类。

7、隐藏委托关系(Hide Delegate)

?

????????如果某些客户端先通过服务对象的字段得到另一个对象(受托类),然后调用后者的函数,那么客户就必须知晓这一层委托关系。万一受托类修改了接口,变化会波及通过服务对象使用它的所有客户端。我可以在服务对象上放置一个简单的委托函数,将委托关系隐藏起来,从而去除这种依赖。这么一来,即使将来委托关系发生变化,变化也只会影响服务对象,而不会直接波及所有客户端。

? ? ? ? 例如:现在有两个类,代表“人”的Person和代表“部门”的Department。有些客户端希望知道某人的经理是谁,为此,它必须先取得Department对象。

// 客户端必须知道 要调部门 才能知道经理
manager = aPerson.department.manager;

? ? ? ? 这样的编码就对客户端揭露了Department的工作原理,于是客户知道:Department负责追踪“经理”这条信息。如果对客户隐藏Department,可以减少耦合。为了这一目的,我在Person中建立一个简单的委托函数。

class Person {
    get manager() {
        // 将部门这层封装起来,使客户端不感知
        return this.department.manager;
    }
}

manager = aPerson.manager;

8、移除中间人(Remove Middle Man)

?

????????刚刚谈到了“封装受托对象”的好处。但是这层封装也是有代价的。每当客户端要使用受托类的新特性时,你就必须在服务端添加一个简单委托函数。随着受托类的特性(功能)越来越多,更多的转发函数就会使人烦躁。服务类完全变成了一个中间人,此时就应该让客户直接调用受托类。
????????很难说什么程度的隐藏才是合适的。6个月前恰如其分的封装,现今可能就显得笨拙。重构的意义就在于:你永远不必说对不起——只要把出问题的地方修补好就行了。

? ? ? ? 做法就是把7中的例子反过来……

9、替换算法(Substitute Algorithm)

? ? ? ? 改进算法。

文章来源:https://blog.csdn.net/m0_49499183/article/details/135720009
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。