當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

一文读懂 @Decorator 装饰器——理解 VS Code 源码的基础

發布時間：2024/2/28 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了一文读懂 @Decorator 装饰器——理解 VS Code 源码的基础小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

作者：easonruan，騰訊 CSIG 前端開發工程師

1. 裝飾器的樣子

我們先來看看 Decorator 裝飾器長什么樣子，大家可能沒在項目中用過 Decorator 裝飾器，但多多少少會看過下面裝飾器的寫法：

/*?Nest.Js?cats.controller.ts?*/ import?{?Controller,?Get?}?from?'@nestjs/common';@Controller('cats') export?class?CatsController?{@Get()findAll():?string?{return?'This?action?returns?all?cats';} }

摘自《Nest.Js》官方文檔

上述代碼大家可以不著急去理解，主要是讓大家對裝飾器有一個初步了解，后面我們會逐一分析 Decorator 裝飾器的實現原理以及具體用法。

2. 為什么要理解裝飾器

2.1 淺一點來說，理解才能讀懂 VS Code 源碼

Decorator 裝飾器是 ECMAScript 的語言提案，目前還處于 stage-2 階段，但是借助 TypeScript 或者 Babel，已經有大量的優秀開源項目深度用上它了，比如：VS Code, Angular, Nest.Js(后端 Node.js 框架), TypeORM, Mobx(5) 等等

舉個例子：https://github.com/microsoft/vscode/blob/main/src/vs/workbench/services/editor/browser/codeEditorService.ts#L22

作為一個有追求的程序員，你可能會問：上面代碼的裝飾器代表什么含義？去掉裝飾器后能不能正常運行？

如果沒弄懂裝飾器，很難讀懂 VS Code 這些優秀項目源碼的核心思想。所以說你不需要熟練使用裝飾器，但一定要理解裝飾器的用法。

2.2 深一點來說，理解才能弄懂 AOP , IoC, DI 等優秀編程思想

1.AOP 即面向切面編程 (Aspect Oriented Programming)

AOP 主要意圖是將日志記錄，性能統計，安全控制，異常處理等代碼從業務邏輯代碼中劃分出來，將它們獨立到非指導業務邏輯的方法中，進而改變這些行為的時候不影響業務邏輯的代碼。

簡而言之，就是“優雅”的把“輔助功能邏輯”從“業務邏輯”中分離，解耦出來。

圖摘自《簡談前端開發中的 AOP(一) -- 前端 AOP 的實現思路》

2.IoC 即控制反轉 (Inversion of Control)，是解耦的一種設計理念

3.DI 即依賴注入 (Dependency Injection)，是 IoC 的一種具體實現

使用 IoC 前：

使用 IoC 后：

圖摘自《兩張圖讓你理解 IoC (控制反轉)》

IoC 控制反轉的設計模式可以大幅度地降低了程序的耦合性。而 Decorator 裝飾器在 VS Code 的控制反轉設計模式里，其主要作用是實現 DI 依賴注入的功能和精簡部分重復的寫法。由于該步驟實現較為復雜，我們先從簡單的例子為切入點去了解裝飾器的基本原理。

3. 裝飾器的概念區分

在理解裝飾器之前，有必要先對裝飾器的 3 個概念進行區分。

3.1 Decorator Pattern (裝飾器模式)

是一種抽象的設計理念，核心思想是在不修改原有代碼情況下，對功能進行擴展。

3.2 Decorator (裝飾器)

是一種特殊的裝飾類函數，是一種對裝飾器模式理念的具體實現。

3.3 @Decorator (裝飾器語法)

是一種便捷的語法糖(寫法)，通過 @ 來引用，需要編譯后才能運行。理解了概念之后可以知道：裝飾器的存在就是希望實現裝飾器模式的設計理念。

說法 1：在不修改原有代碼情況下，對功能進行擴展。也就是對擴展開放，對修改關閉。

說法 2：優雅地把“輔助性功能邏輯”從“業務邏輯”中分離，解耦出來。（AOP 面向切面編程的設計理念）

4. 裝飾器的實戰：記錄函數耗時

現在有一個關羽(GuanYu) 類，它有兩個函數方法：attack(攻擊) 和 run(奔跑)

class?GuanYu?{attack()?{console.log('揮了一次大刀')}run()?{console.log('跑了一段距離')} }

而我們都是優秀的程序員，時時刻刻都有著經營思維 (性能優化)，因此想給關羽(GuanYu) 的函數方法提前做好準備：記錄關羽的每一次 attack(攻擊) 和 run(奔跑) 的執行時間，以便于后期做性能優化。

4.1 做法一：復制粘貼，不用思考一把梭就是干

拿到需求，不用多想，立刻在函數前后，添加記錄函數耗時的邏輯代碼，并復制粘貼到其他地方：

class?GuanYu?{attack()?{ +???const?start?=?+new?Date()console.log('揮了一次大刀') +???const?end?=?+new?Date() +???console.log(`耗時:?${end?-?start}ms`)}run()?{ +???const?start?=?+new?Date()console.log('跑了一段距離') +???const?end?=?+new?Date() +???console.log(`耗時:?${end?-?start}ms`)} }

但是這樣直接修改原函數代碼有以下幾個問題：

理解成本高

統計耗時的相關代碼與函數本身邏輯并無關系，對函數結構造成了破壞性的修改，影響到了對原函數本身的理解

維護成本高

如果后期還有更多類似的函數需要添加統計耗時的代碼，在每個函數中都添加這樣的代碼非常低效，也大大提高了維護成本

4.2 做法二：裝飾器模式，不修改原代碼擴展功能

4.2.1 裝飾器前置基礎知識

在開始用裝飾器實現之前必須掌握以下基礎：

Object.getOwnPropertyDescriptor()

返回指定對象上一個自有屬性對應的屬性描述符

var?a?=?{?b:?()?=>?{}?} var?descriptor?=?Object.getOwnPropertyDescriptor(a,?'b') console.log(descriptor) /***?{*???configurable:?true,??//?可配置的*???enumerable:?true,????//?可枚舉的*???value:?()?=>?{},?????//?該屬性對應的值（數值，對象，函數等）*???writable:?true,??????//?可寫入的*?}*/

這里要注意一個點是：value 可以是 JavaScript 的任意值，比如函數方法，正則，日期等

Object.defineProperty()

在一個對象上定義或修改一個屬性的描述符：

const?object1?=?{};Object.defineProperty(object1,?'property1',?{value:?'ThisIsNotWritable',writable:?false });object1.property1?=?'newValue'; //?throws?an?error?in?strict?modeconsole.log(object1.property1); //?expected?output:?'ThisIsNotWritable'

4.2.2 【重點】手寫一個裝飾器函數

有了上面的兩個基礎后，我們開始利用裝飾器模式的設計理念，用純函數的形式寫一個裝飾器，實現記錄函數耗時功能。為了讓大家更深刻理解裝飾器的原理，我們先不用 @Decorator 這個語法糖。

下面代碼是本文的重點，大家可以放慢閱讀速度，理解后再繼續往下看：

//?裝飾器函數 function?decoratorLogTime(target,?key)?{const?targetPrototype?=?target.prototype//?Step1?備份原來類構造器上的屬性描述符?Descriptorconst?oldDescriptor?=?Object.getOwnPropertyDescriptor(targetPrototype,?key)//?Step2?編寫裝飾器函數業務邏輯代碼const?logTime?=?function?(...arg)?{//?Before?鉤子let?start?=?+new?Date()try?{//?執行原來函數return?oldDescriptor.value.apply(this,?arg)?//?調用之前的函數}?finally?{//?After?鉤子let?end?=?+new?Date()console.log(`耗時:?${end?-?start}ms`)}}//?Step3?將裝飾器覆蓋原來的屬性描述符的?valueObject.defineProperty(targetPrototype,?key,?{...oldDescriptor,value:?logTime}) }class?GuanYu?{attack()?{console.log('揮了一次大刀')}run()?{console.log('跑了一段距離')} } //?Step4?手動執行裝飾器函數，裝飾?GuanYu?的?attack?函數 decoratorLogTime(GuanYu,?'attack') //?Step4?手動執行裝飾器函數，裝飾?GuanYu?的?run?函數 decoratorLogTime(GuanYu,?'run')const?guanYu?=?new?GuanYu() guanYu.attack() //?揮了一次大刀 //?耗時:?0ms guanYu.run() //?跑了一段距離 //?耗時:?0ms

以上就是裝飾器的具體實現方法，其核心思路是：

Step1 備份原來類構造器 (Class.prototype) 的屬性描述符 (Descriptor)

利用 Object.getOwnPropertyDescriptor 獲取

Step2 編寫裝飾器函數業務邏輯代碼

利用執行原函數前后鉤子，添加耗時統計邏輯

Step3 用裝飾器函數覆蓋原來屬性描述符的 value

利用 Object.defineProperty 代理

Step4 手動執行裝飾器函數，裝飾 Class(類) 指定屬性

從而實現在不修改原代碼的前提下，執行額外邏輯代碼

5. @Decorator 裝飾器語法糖

但上一步 4.2.2 手寫的裝飾器函數存在兩個可優化的點：

是否可以讓裝飾器函數更關注業務邏輯？

Step1, Step2 是通用邏輯的，每個裝飾器都需要實現，簡單來說就是可復用的。

是否可以讓裝飾器寫法更簡單？

純函數實現的裝飾器，每裝飾一個屬性都要手動執行裝飾器函數，詳見 Step4 步驟。針對上述優化點，裝飾器草案中有一顆特別甜的語法糖，也就是 @Decorator ，它能夠幫你省去很多繁瑣的步驟來用上裝飾器。

只需要在想使用的裝飾器前加上@符號，裝飾器就會被應用到目標上。

5.1 @Decorator 語法糖的便捷性

下面我們用 @Decorator 的寫法，來實現同樣的功能，看看代碼量可以精簡多少：

//?Step2?編寫裝飾器函數業務邏輯代碼 function?logTime(target,?key,?descriptor)?{const?oldMethed?=?descriptor.valueconst?logTime?=?function?(...arg)?{let?start?=?+new?Date()try?{return?oldMethed.apply(this,?arg)?//?調用之前的函數}?finally?{let?end?=?+new?Date()console.log(`耗時:?${end?-?start}ms`)}}descriptor.value?=?logTimereturn?descriptor }class?GuanYu?{//?Step4?利用?@?語法糖裝飾指定屬性@logTimeattack()?{console.log('揮了一次大刀')}//?Step4?利用?@?語法糖裝飾指定屬性@logTimerun()?{console.log('跑了一段距離')} }const?guanYu?=?new?GuanYu() guanYu.attack() //?[LOG]:?揮了一次大刀 //?[LOG]:?耗時:?3ms guanYu.run() //?[LOG]:?跑了一段距離 //?[LOG]:?耗時:?3ms

為了讓更直觀了解上述代碼是否可以編譯后正常執行，

我們可以從 TypeScript Playground 直接看到編譯后的代碼以及運行結果，

注意！為了方便理解，記得關閉配置 emitDecoratorMetadata 禁止輸出元數據，

元數據是另一個比較復雜的知識點，我們本篇文章先跳過

關閉后編譯的代碼會更簡單

我們打開上面代碼的在線 Playground 鏈接，點擊 Run 運行按鈕，即可看到其正常運行和輸出結果：

對比純手寫的裝飾器，用 @Decorator 語法糖可以省去 2 個重復的步驟：

Step1 備份原來類構造器 (Class.prototype) 的屬性描述符 (Descriptor)
const?oldDescriptor?=?Object.getOwnPropertyDescriptor(targetPrototype,?key)
Step3 用裝飾器函數覆蓋原來屬性描述符的 value
Object.defineProperty(targetPrototype,?key,?{...oldDescriptor,value:?logTime })

開發者僅需兩步即可實現裝飾器的功能，可以更專注于裝飾器本身的業務邏輯：

Step2 編寫裝飾器函數業務邏輯代碼
function?logTime(target,?key,?descriptor)?{const?oldMethed?=?descriptor.valueconst?logTime?=?function?(...arg)?{let?start?=?+new?Date()try?{return?oldMethed.apply(this,?arg)?//?調用之前的函數}?finally?{let?end?=?+new?Date()console.log(`耗時:?${end?-?start}ms`)}}descriptor.value?=?logTimereturn?descriptor }
Step4 利用 @ 語法糖裝飾指定屬性
@logTime attack()?{console.log('揮了一次大刀') }

5.2 【重點】分析 @Decorator 語法糖編譯后的代碼

@Decorator 語法糖很甜，但卻不能直接食用。因為裝飾器目前僅僅是 ECMAScript 的語言提案，還處于 stage-2 階段，無論是最新版的 Chrome 瀏覽器還是 Node.js 都不能直接運行帶有 @Decorator 語法糖的代碼。我們需要借助 TypeScript 或者 Babel 的能力，將源碼編譯后才能正常運行。而在 TypeSciprt Playground 上，我們可以直接看到編譯后代碼。

為了更清晰容易理解，我們把編譯后的業務代碼先注釋掉，只看裝飾器實現的相關代碼：

"use?strict"; //?Part1?裝飾器工具函數(__decorate)的定義 var?__decorate?=?(this?&&?this.__decorate)?||?function?(decorators,?target,?key,?desc)?{var?c?=?arguments.length,?r?=?c?<?3???target?:?desc?===?null???desc?=?Object.getOwnPropertyDescriptor(target,?key)?:?desc,?d;if?(typeof?Reflect?===?"object"?&&?typeof?Reflect.decorate?===?"function")?r?=?Reflect.decorate(decorators,?target,?key,?desc);else?for?(var?i?=?decorators.length?-?1;?i?>=?0;?i--)?if?(d?=?decorators[i])?r?=?(c?<?3???d(r)?:?c?>?3???d(target,?key,?r)?:?d(target,?key))?||?r;return?c?>?3?&&?r?&&?Object.defineProperty(target,?key,?r),?r; };function?logTime(target,?key,?descriptor)?{//?... }class?GuanYu?{//?... }//?Part2?裝飾器工具函數(__decorate)的執行 __decorate([logTime],?GuanYu.prototype,?"attack",?null); __decorate([logTime],?GuanYu.prototype,?"run",?null);//?...

上述代碼核心點是兩個部分，一個是定義，一個是執行。定義部分較為復雜，我們先從執行入手：Part2 裝飾器工具函數(__decorate)的執行會傳入以下 4 個參數：

裝飾器業務邏輯函數

類的構造器

類的構造器屬性名

屬性描述符(可以為 null)

為了方便理解 Part1 裝飾器工具函數 __decorate 的定義，我們需要精簡 __decorate 的函數代碼，讓它變成最簡單的樣子，而精簡代碼的前提是收集條件：

條件 1 (this && this.__decorate) 可刪除

這里的 this 是指 window 對象，這一步的含義是避免重復定義 __decorate 函數，屬于輔助代碼，可刪掉。

條件 2 c < 3 === false

Part1 的 c = arguments.length 代表參數的個數，由 Part2 我們知道工具函數會傳入 4 個參數，因此在本次案例中 c < 3 參數個數小于 3 的情況不存在，即 c < 3 === false，

條件 3 c > 3 === true

本次案例中 c > 3 參數大于 3 的情況存在，即 c > 3 === true 。

條件 4 desc === null

同時在 Part1 我們知道第四個參數 desc 傳入的值就是 null ，即 desc === null

條件 5 typeof Reflect !== "object"

Reflect 反射是 ES6 的語法，本文為了更容易理解，暫不引入新的 ES6 特性和語法，讓環境默認為 ES5，即不存在 Reflect 對象，即 typeof Reflect !== "object"，有了上述條件后，我們可以進一步精簡 __decorate 的方法

代碼片段 1：

r?=?c?<?3???target?:?desc?===?null???desc?=?Object.getOwnPropertyDescriptor(target,?key)?:?desc//?根據?c?<?3?===?false?,?desc?===?null?條件 //?精簡后r?=?desc?=?Object.getOwnPropertyDescriptor(target,?key) //?r?和?desc?此時代表的是屬性的描述符?Descriptor

代碼片段 2：

if?(d?=?decorators[i])?r?=?(c?<?3???d(r)?:?c?>?3???d(target,?key,?r)?:?d(target,?key))?||?r;//?根據?c?<?3?===?false?,?c?>?3?===?true?條件 //?精簡后if?(d?=?decorators[i])?r?=?d(target,?key,?r)?||?r;

代碼片段 3：

if?(typeof?Reflect?===?"object"?&&?typeof?Reflect.decorate?===?"function")?r?=?Reflect.decorate(decorators,?target,?key,?desc);//?為了方便理解，本案例暫認為?Reflect?不存在 //?精簡后//?空

代碼片段 4：

return?c?>?3?&&?r?&&?Object.defineProperty(target,?key,?r),?r;//?根據?c?>?3?===?true,?r?是屬性描述符，必定存在 //?精簡后Object.defineProperty(target,?key,?r) return?r;

精簡后整體代碼：

var?__decorate?=?function?(decorators,?target,?key,?desc)?{var?c?=?arguments.length;//?Step1?備份原來類構造器?(Class.prototype)?的屬性描述符?(Descriptor)var?r?=?desc?=?Object.getOwnPropertyDescriptor(target,?key),var?d;for?(var?i?=?decorators.length?-?1;?i?>=?0;?i--)?{//?d?為裝飾器業務邏輯函數if?(d?=?decorators[i])?{//?執行?d，并傳入?target?類構造器，key?屬性名，r?屬性描述符r?=?d(target,?key,?r)?||?r;}}//?Step3?用裝飾器函數覆蓋原來屬性描述符Object.defineProperty(target,?key,?r)return?r; };

代碼經過精簡之后核心原理還是和我們 4.2.2 手寫一個裝飾器函數的原理是一樣的。

Step1 備份原來類構造器 (Class.prototype) 的屬性描述符 (Descriptor)

利用 Object.getOwnPropertyDescriptor 獲取

**Step3 用裝飾器函數覆蓋原來屬性描述符的 value **

利用 Object.defineProperty 代理

TypeScript 對裝飾器編譯后的代碼，只不過是把裝飾器可復用的邏輯抽離成一個工具函數，方便復用而已。分析到這里，是不是對 @Decorator 裝飾器最根本的實現有了更深入的了解？從上面的例子，我們也進一步驗證了：

Decorator Pattern 裝飾器模式的設計理念：在不修改原有代碼情況下，對功能進行擴展

Decorator 裝飾器的具體實現，本質是函數，參數有 target, key, descriptor

@Decoretor 是裝飾器的一種語法糖，只是一種便捷寫法，編譯后本質還是一個函數

6. 帶參數的裝飾器：裝飾器工廠函數

在上面的「記錄函數耗時」例子中，如果我們希望在日志前面加個可變的標簽，如何實現？

答案是使用帶參數的裝飾器

重點：logTime 是個高階函數，可以理解成裝飾器工廠函數，其接收參數執行后，返回一個裝飾器函數

function?logTime(tag)?{?//?這是一個裝飾器工廠函數return?function(target,?key,?descriptor)?{??//?這是裝飾器const?oldMethed?=?descriptor.valueconst?logTime?=?function?(...arg)?{let?start?=?+new?Date()try?{return?oldMethed.apply(this,?arg)}?finally?{let?end?=?+new?Date()console.log(`【${tag}】耗時:?${end?-?start}ms`)}}descriptor.value?=?logTimereturn?descriptor} }class?GuanYu?{@logTime('攻擊')attack()?{console.log('揮了一次大刀')},@logTime('奔跑')run()?{console.log('跑了一段距離')} }//?...

編譯后：

//?...__decorate([logTime('攻擊')],?GuanYu.prototype,?"attack",?null); __decorate([logTime('奔跑')],?GuanYu.prototype,?"run",?null);//?...

看了編譯后的代碼，我們就很容易知道帶參數裝飾器的具體實現原理，無非是直接先執行裝飾器工廠函數，此時傳入對應參數，然后返回一個新的裝飾器業務邏輯的函數。

7. 五種裝飾器：類、屬性、方法、參數、訪問器

我們上面學了那么多裝飾器的內容，其實只學了一種裝飾器：方法裝飾器，而裝飾器一共有 5 種類型可被我們使用：

類裝飾器

屬性裝飾器

方法裝飾器

訪問器裝飾器

參數裝飾器

先來個全家福，然后我們逐一攻破

//?類裝飾器 @classDecorator class?GuanYu?{//?屬性裝飾器@propertyDecoratorname:?string;//?方法裝飾器@methodDecoratorattack?(//?參數裝飾器@parameterDecoratormeters:?number)?{}//?訪問器裝飾器@accessorDecoratorget?horse()?{} }

7.1 類裝飾器

類型聲明：

//?類裝飾器 function?classDecorator(target:?any)?{return?//?... };

@參數：只接受一個參數

target: 類的構造器

@返回：如果類裝飾器返回了一個值，她將會被用來代替原有的類構造器的聲明
因此，類裝飾器適合用于繼承一個現有類并添加一些屬性和方法。例如我們可以添加一個 addToJsonString 方法給所有的類來新增一個 toString 方法

function?addToJSONString(target)?{return?class?extends?target?{toJSONString()?{return?JSON.stringify(this);}}; }@addToJSONString class?C?{public?foo?=?"foo";public?num?=?24; }console.log(new?C().toJSONString()) //?[LOG]:?"{"foo":"foo","num":24}"

7.2 方法裝飾器

已經在上面章節介紹過利用方法裝飾器來實現「記錄函數耗時」功能，現在我們重新復習下

類型聲明：

//?方法裝飾器 function?methodDecorator(target:?any,?propertyKey:?string,?descriptor:?PropertyDescriptor)?{return?//?... };

@參數：

target: 對于靜態成員來說是類的構造器，對于實例成員來說是類的原型鏈

propertyKey: 屬性的名稱

descriptor: 屬性的描述器

@返回：如果返回了值，它會被用于替代屬性的描述器。
利用方法裝飾器我們可以實現更多的具體場景，比如「打印 Request 的請求參數和結果」功能：
function?loggerParamsResult(target,?propertyKey,?descriptor)?{const?original?=?descriptor.value;descriptor.value?=?async?function?(...args)?{let?resultlet?errortry?{result?=?await?original.call(this,?...args);}?catch(e)?{error?=?new?Error(e)}if?(error)?{console.error('請求失敗！')console.error('請求參數:?',?...args)console.error('失敗原因:?',?error)}?else?{console.log('請求成功！')console.log('請求參數',?...args)console.log('請求結果:?',?result)}return?result;} }class?App?{@loggerParamsResultrequest(data)?{return?new?Promise((resolve,?reject)?=>?{const?random?=?Math.random()?>?0.5if?(random)?{resolve(random)}?else?{reject(random)}})} }const?app?=?new?App(); app.request({?url:?'https://www.tencent.com'});//?[LOG]:?"請求成功！" //?[LOG]:?"請求參數",??{ //???"url":?"https://www.tencent.com" //?} //?[LOG]:?"請求結果:?",??true//?[ERR]:?"請求失敗！" //?[ERR]:?"請求參數:?",??{ //???"url":?"https://www.tencent.com" //?} //?[ERR]:?"失敗原因:?",??false
總結：
無論是「記錄函數耗時」還是「打印 Request 的請求參數和結果」，本質都是在實現 Before / After 鉤子，因此我們只需要記住方法裝飾器可以實現與 Before / After 鉤子 相關的場景功能。
課后題：
除了上述兩個例子，大家還能想到方法裝飾器有什么好的應用場景嗎？
7.3 屬性裝飾器
類型聲明：
//?屬性裝飾器 function?propertyDecorator(target:?any,?propertyKey:?string)?{}
- @參數: 只接受兩個參數，少了 descriptor 描述器
target: 對于靜態成員來說是類的構造器，對于實例成員來說是類的原型鏈
propertyKey: 屬性的名稱
@返回: 返回的結果將被忽略
利用屬性裝飾器，我們可以實現一個非常簡單的屬性監聽功能，當屬性改變時觸發指定函數：
function?observable(fnName)?{??//?裝飾器工廠函數return?function?(target:?any,?key:?string):?any?{??//?裝飾器let?prev?=?target[key];Object.defineProperty(target,?key,?{set(next)?{target[fnName](prev,?next);prev?=?next;}})} }class?Store?{@observable('onCountChange')count?=?-1;onCountChange(prev,?next)?{console.log('>>>?count?has?changed!')console.log('>>>?prev:?',?prev)console.log('>>>?next:?',?next)} }const?store?=?new?Store(); store.count?=?10//?[LOG]:?">>>?count?has?changed!" //?[LOG]:?">>>?prev:?",??undefined //?[LOG]:?">>>?next:?",??-1 //?[LOG]:?">>>?count?has?changed!" //?[LOG]:?">>>?prev:?",??-1 //?[LOG]:?">>>?next:?",??10
7.4 訪問器裝飾器
訪問器裝飾器總體上講和方法裝飾器很接近，唯一的區別在于第三個參數 descriptor 描述器中有的 key 不同：
方法裝飾器的描述器的 key 為：
- value
- writable
- enumerable
- configurable
訪問器裝飾器的描述器的 key 為：
- get
- set
- enumerable
- configurable
類型聲明：
//?訪問器裝飾器 function?methodDecorator(target:?any,?propertyKey:?string,?descriptor:?PropertyDescriptor)?{return?//?... };
例如，我們可以將某個屬性在賦值的時候做一層代理，額外相加一個值：
function?addExtraNumber(num)?{??//?裝飾器工廠函數return?function?(target,?propertyKey,?descriptor)?{?//?裝飾器const?original?=?descriptor.set;descriptor.set?=?function?(value)?{const?newObj?=?{}Object.keys(value).forEach(key?=>?{newObj[key]?=?value[key]?+?num})return?original.call(this,?newObj)}} }class?C?{private?_point?=?{?x:?0,?y:?0?}@addExtraNumber(2)set?point(value:?{?x:?number,?y:?number?})?{this._point?=?value;}get?point()?{return?this._point;} }const?c?=?new?C(); c.point?=?{?x:?1,?y:?1?};console.log(c.point)//?[LOG]:?{ //???"x":?3, //???"y":?3 //?}
7.5 參數裝飾器
類型聲明：
//?參數裝飾器 function?parameterDecorator(target:?any,?methedKey:?string,?parameterIndex:?number)?{}
- @參數：接收三個參數
target: 對于靜態成員來說是類的構造器，對于實例成員來說是類的原型鏈
methedKey: 方法的名稱，注意！是方法的名稱，而不是參數的名稱
parameterIndex: 參數在方法中所處的位置的下標
@返回：返回的值將會被忽略
單獨的參數裝飾器能做的事情很有限，它一般都被用于記錄可被其它裝飾器使用的信息。
function?Log(target,?methedKey,?parameterIndex)?{console.log(`方法名稱?${methedKey}`);console.log(`參數順序?${parameterIndex}`); }class?GuanYu?{attack(@Log?person,?@Log?dog)?{console.log(`向?${person}?揮了一次大刀`)} }//?[LOG]:?"方法名稱?attack" //?[LOG]:?"參數順序?0"
7.6 裝飾器參數總結
8. 裝飾器順序
8.1 同種裝飾器組合順序：洋蔥模型
如果同一個方法有多個裝飾器，其執行順序是怎樣的？
答案：
以方法裝飾器為例，同種裝飾器組合后，其順序會像剝洋蔥一樣，
先從外到內進入，然后由內向外執行。和 Koa 的中間件順序類似。
function?dec(id){console.log('裝飾器初始化',?id);return?function?(target,?property,?descriptor)?{console.log('裝飾器執行',?id);} }class?Example?{@dec(1)@dec(2)method(){} }//?裝飾器初始化?1 //?裝飾器初始化?2 //?裝飾器執行?2 //?裝飾器執行?1 I2b3cL.png
其原理，看編譯后的代碼就非常清楚：
重點：
dec(1), dec(2) 初始化時就執行
for (var i = decorators.length - 1; i >= 0; i--) 是從右向左，倒敘執行

8.2 不同類型裝飾器順序：有規則有規律

實例成員：(參數 > 方法) / 訪問器 / 屬性裝飾器 (按順序)
靜態成員：(參數 > 方法) / 訪問器 / 屬性裝飾器 (按順序)
構造器：參數裝飾器
類裝飾器

多種裝飾器優先級為：

實例成員最高，內部成員里面的裝飾器則按定義順序執行，

依次排下來，類裝飾器最低

9. 裝飾器總結

9.1 應用場景

裝飾器很像是組合一系列函數，類似于高階函數和類。

合理利用裝飾器對一些非內部邏輯相關的代碼進行封裝提煉，

能夠幫助我們快速完成重復性的工作，節省時間，極大提高開發效率。

類裝飾器

可添加額外的方法和屬性，比如：擴展 toJSONString 方法

方法裝飾器

可實現 Before / After 鉤子功能，比如：記錄函數耗時，打印 request 參數結果，節流防抖

屬性裝飾器

可監聽屬性改變觸發其他事件，比如：實現 count 監聽器

訪問器裝飾器
參數裝飾器

當然，還有更多可以使用裝飾器的場景等著我們去發現

運行時類型檢查
依賴注入

9.2 優點

在不修改原有代碼情況下，對功能進行擴展。也就是對擴展開放，對修改關閉。
優雅地把“輔助性功能邏輯”從“業務邏輯”中分離，解耦出來。（AOP 面向切面編程的設計理念）
裝飾類和被裝飾類可以獨立發展，不會相互耦合
裝飾模式是 Class 繼承的一個替代模式，可以理解成組合

9.3 缺點

但是糖再好吃，也不要吃太多，容易壞牙齒的，濫用過多裝飾器會導致很多問題：

理解成本：過多帶業務功能的裝飾器會使代碼本身邏輯變得撲朔迷離
調試成本：裝飾器層次增多，會增加調試成本，很難追溯到一個 Bug 是在哪一層包裝導致的

9.4 注意事項

裝飾器的功能邏輯代碼一定是輔助性的

比如日志記錄，性能統計等，這樣才符合 AOP 面向切面編程的思想，如果把過多的業務邏輯寫在了裝飾器上，效果會適得其反。

裝飾器語法尚未定案以及未被納入 ES 標準，標準化的過程還需要很長時間

由于裝飾器語法未來制定的標準可能與當前的裝飾器實現方案有所不同，Mobx 6 出于兼容性的考慮，放棄了裝飾器的用法，并建議使用 makeObservable / makeAutoObservable 代替。

詳情請查看：https://zh.mobx.js.org/enabling-decorators.html

裝飾器提案目前進度：https://github.com/tc39/proposal-decorators

最近熱文：

5000 萬行以上大型代碼倉庫工程實踐

帶你快速了解 Docker 和 Kubernetes

? ??

? ? ? ? ? ?? ? ??? “科技公益，向善而生”

? ? ? ? ????2021科技公益-系列技術直播來啦！

掃描海報下方二維碼，一鍵預定直播，精彩不容錯過！

點擊下方【閱讀原文】也可直接預約直播！

總結

以上是生活随笔為你收集整理的一文读懂 @Decorator 装饰器——理解 VS Code 源码的基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：腾讯极客挑战赛正式开赛！「鹅罗斯方块」开
下一篇：别琢磨了，七夕礼物都给你想好了