做网站设计多少钱,访问网页,秦皇岛建设局官方网站,优化网站加载速度1、封装记录#xff08;Encapsulate Record#xff09; 一些记录性结构#xff08;例如hash、map、hashmap、dictionary等#xff09;#xff0c;一条记录上持有什么字段往往不够直观。如果其使用范围比较宽#xff0c;这个问题往往会造成许多困扰。所以#xff0c;记录…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;
elsereturn basePrice * 0.98; 应该变为
// 构建一个查询用来替代那个变量
get basePrice() {this._quantity * this._itemPrice;}...if (this.basePrice 1000)return this.basePrice * 0.95;
elsereturn 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 改进算法。
