装饰器模式通过@语法为类和方法非侵入式添加功能,如日志、权限、性能监控等横切关注点,提升代码复用性与可维护性。

JavaScript 装饰器模式,说白了,就是一种非常优雅、声明式地增强类和方法功能的方式。它允许你在不修改原有代码结构的前提下,为它们“附加”新的行为或元数据。在我看来,这就像给你的代码穿上了一件件定制的“外套”,让它们在保持核心功能不变的同时,拥有了更多酷炫的能力。这套方案的核心价值在于解耦和复用,让那些原本散落在各处的横切关注点(比如日志、权限、性能监控)能够集中管理,大大提升了代码的可读性和可维护性。
装饰器(Decorators)本质上就是一种特殊类型的函数,它能够修改或替换类、方法、访问器、属性或参数的定义。在 JavaScript 中,我们通常通过
@
@decoratorName
它的工作原理是,当你定义一个类或方法时,装饰器会在它们被定义时立即执行。它会接收到被装饰的目标(比如类构造函数、方法的描述符等),然后返回一个修改后的目标,或者干脆返回一个新的目标来替换原来的。这种“运行时修改定义”的能力,使得我们可以在不侵入原有业务逻辑的情况下,注入各种辅助功能。
举个最简单的例子,如果你想给一个方法加上日志功能,传统做法可能是在方法内部的开头和结尾都写上
console.log
@log
// 假设这是我们的日志装饰器
function log(target, propertyKey, descriptor) {
const originalMethod = descriptor.value;
descriptor.value = function (...args) {
console.log(`[LOG] Calling method: ${propertyKey.toString()} with args: ${JSON.stringify(args)}`);
const result = originalMethod.apply(this, args);
console.log(`[LOG] Method ${propertyKey.toString()} returned: ${JSON.stringify(result)}`);
return result;
};
return descriptor;
}
class Calculator {
@log
add(a, b) {
return a + b;
}
@log
subtract(a, b) {
return a - b;
}
}
const calc = new Calculator();
calc.add(2, 3);
// [LOG] Calling method: add with args: [2,3]
// [LOG] Method add returned: 5
calc.subtract(5, 1);
// [LOG] Calling method: subtract with args: [5,1]
// [LOG] Method subtract returned: 4可以看到,
@log
add
subtract
说实话,在日常前端开发中,我们经常会遇到一些横切关注点,它们本身不是核心业务逻辑,却又无处不在,比如数据校验、权限控制、性能统计、事件绑定等等。这些东西如果每次都手写一遍,或者通过继承、组合的方式去处理,代码会变得非常臃肿,而且难以维护。装饰器在这方面简直是“神来之笔”,它能把这些重复性工作抽离出来,以一种非常优雅的方式注入到目标代码中。
1. 性能监控与埋点: 假设你想知道一个方法执行了多久,或者某个组件渲染了多少次。传统做法可能是在方法开始前记录时间,结束后计算差值。但有了装饰器,你可以创建一个
@measurePerformance
function measurePerformance(target, propertyKey, descriptor) {
const originalMethod = descriptor.value;
descriptor.value = function (...args) {
const start = performance.now();
const result = originalMethod.apply(this, args);
const end = performance.now();
console.log(`[Performance] Method ${propertyKey.toString()} executed in ${end - start}ms.`);
return result;
};
return descriptor;
}
class DataProcessor {
@measurePerformance
processLargeDataSet(data) {
// 模拟耗时操作
let sum = 0;
for (let i = 0; i < 1000000; i++) {
sum += i;
}
return data.length + sum;
}
}
const processor = new DataProcessor();
processor.processLargeDataSet([1, 2, 3]);
// [Performance] Method processLargeDataSet executed in XXms.2. 权限控制与认证: 在许多应用中,某些操作需要特定的用户权限。你不可能在每个方法里都写一遍
if (!user.hasPermission('admin')) return;@requiresRole('admin')@isAuthenticated
function requiresRole(role) {
return function (target, propertyKey, descriptor) {
const originalMethod = descriptor.value;
descriptor.value = function (...args) {
// 假设这里有一个全局的用户信息或权限检查服务
// 实际应用中会从JWT、Session或Redux Store中获取
const currentUser = { roles: ['user'] }; // 模拟当前用户角色
if (!currentUser.roles.includes(role)) {
console.warn(`[Auth] Access denied for ${propertyKey.toString()}. Required role: ${role}`);
throw new Error(`Permission denied: requires ${role} role.`);
}
return originalMethod.apply(this, args);
};
return descriptor;
};
}
class AdminPanel {
@requiresRole('admin')
deleteUser(userId) {
console.log(`Deleting user: ${userId}`);
// ... 执行删除操作
}
@requiresRole('user') // 即使是普通用户也可以访问
viewDashboard() {
console.log('Viewing dashboard.');
}
}
const adminPanel = new AdminPanel();
try {
adminPanel.deleteUser(123); // 会抛出权限不足的错误
} catch (e) {
console.error(e.message);
}
adminPanel.viewDashboard(); // 正常执行3. 表单验证与数据处理: 在处理用户输入时,验证是必不可少的一环。你可以创建
@validate(schema)
这些例子只是冰山一角。装饰器还能用于自动绑定
this
bind
自己动手写装饰器,其实并不复杂,但有些细节如果不注意,可能会踩到一些坑。这就像搭积木,虽然基本规则简单,但要搭出稳固又好看的结构,还是得讲究技巧。
1. 理解不同类型装饰器的签名: 这是最基础也最关键的一点。装饰器并不是一个万能函数,它根据你装饰的目标类型(类、方法、属性、访问器、参数)接收不同的参数。
(target: Function)
target
(target: Object, propertyKey: string | symbol, descriptor: PropertyDescriptor)
target
propertyKey
descriptor
value
writable
enumerable
configurable
descriptor.value
descriptor
(target: Object, propertyKey: string | symbol)
target
propertyKey
descriptor
(target: Object, propertyKey: string | symbol, descriptor: PropertyDescriptor)
getter
setter
(target: Object, propertyKey: string | symbol, parameterIndex: number)
target
propertyKey
parameterIndex
我个人觉得,最常用也最强大的还是方法装饰器,因为它能直接操作方法的行为。
2. 装饰器工厂 (Decorator Factory): 如果你需要给装饰器传递参数,那么你就需要创建一个“装饰器工厂”。它是一个函数,接收你的参数,然后返回真正的装饰器函数。
// 这是一个接收参数的日志装饰器工厂
function logWithLevel(level = 'INFO') {
return function (target, propertyKey, descriptor) {
const originalMethod = descriptor.value;
descriptor.value = function (...args) {
console.log(`[${level}] Calling method: ${propertyKey.toString()} with args: ${JSON.stringify(args)}`);
return originalMethod.apply(this, args);
};
return descriptor;
};
}
class Task {
@logWithLevel('DEBUG')
doSomething(data) {
console.log('Doing something with:', data);
}
@logWithLevel() // 默认INFO
finishTask() {
console.log('Task finished.');
}
}
const task = new Task();
task.doSomething('payload');
task.finishTask();这里的
logWithLevel
3. this
descriptor.value = function(...)
this
this
originalMethod.apply(this, args)
originalMethod.call(this, ...args)
originalMethod
this
4. 装饰器的执行顺序: 如果一个目标被多个装饰器装饰,它们的执行顺序是从下往上(对于同一行)或者从右往左(如果写在一行)。但最终的“包装”效果是自外向内。这意味着,最靠近目标定义的装饰器会最先执行,然后它的结果会被上一个装饰器接收并处理。理解这个顺序对于调试和预期行为至关重要。
5. 实验性特性: 目前 JavaScript 的装饰器提案(TC39 Stage 3)仍在演进中,这意味着它的语法和行为在未来可能会有微小的变化。尽管 TypeScript 和 Babel 已经提供了支持,并且在实际项目中被广泛使用,但我们仍需意识到它不是一个最终定稿的 ECMAScript 标准。这通常意味着你需要一个构建工具(如 Babel)或 TypeScript 来转译你的代码。
6. 避免过度使用: 装饰器虽好,但并非银弹。过度使用装饰器可能会让代码变得难以理解和调试,因为它隐藏了实际的逻辑流。有时候,简单的高阶函数或组合模式反而更清晰。选择合适的场景,让装饰器真正发挥其声明式、非侵入的优势,而不是为了用而用。
这个问题问得好,因为在很多场景下,它们确实能解决类似的问题,都是关于“增强”现有功能。但它们在实现方式、适用场景和语义上,还是有挺大区别的。在我看来,它们就像是工具箱里不同形状的扳手,虽然都能拧螺丝,但有些螺丝用特定的扳手会更顺手。
高阶函数 (Higher-Order Functions, HOF):
map
filter
reduce
withLogger(func)
// HOF 示例
function withLogger(fn) {
return function (...args) {
console.log(`[HOF Log] Calling ${fn.name} with args:`, args);
const result = fn.apply(this, args);
console.log(`[HOF Log] ${fn.name} returned:`, result);
return result;
};
}
function add(a, b) {
return a + b;
}
const loggedAdd = withLogger(add);
loggedAdd(10, 20);高阶组件 (Higher-Order Components, HOC):
withRouter
connect
// HOC 示例 (React 伪代码)
function withAuth(WrappedComponent) {
return class extends React.Component {
render() {
// 假设这里有认证逻辑
const isAuthenticated = true; // 模拟
if (!isAuthenticated) {
return <p>请登录</p>;
}
return <WrappedComponent {...this.props} currentUser={{ name: 'John Doe' }} />;
}
};
}
class MyComponent extends React.Component {
render() {
return <p>欢迎, {this.props.currentUser.name}</p>;
}
}
const AuthMyComponent = withAuth(MyComponent);
// <AuthMyComponent />装饰器 (Decorators):
@
该如何选择?
我觉得,选择哪种方案,主要取决于你的目标、上下文以及你所处的生态系统。
如果你在处理类和类的方法: 装饰器往往是最佳选择。它以一种非常优雅、声明式的方式,直接在定义点附近增强功能。比如日志、性能监控、权限检查、自动绑定
this
如果你在进行纯函数式编程,或者需要高度灵活的函数组合: HOF 是你的不二之选。它们不依赖任何特殊语法,能够以非常细粒度的方式组合函数。例如,数据转换管道(
compose(f, g, h)
如果你在 React 组件中复用逻辑,并且你的项目还在使用类组件: HOC 仍然是一个有效的模式,尤其是在 Hooks 出现之前。但现在,React Hooks 已经能够解决 HOC 的大部分问题,并且以更简洁、更直接的方式。所以,在新的 React 项目中,HOC 的使用频率已经大大降低了。
混合使用: 很多时候,你可能需要混合使用这些模式。比如,你可能用装饰器来处理类方法级别的横切关注点,然后用 HOF 来处理一些纯函数的数据转换。在 React 中,你甚至可以用装饰器来简化 HOC 的应用(比如
@withAuth
总结一下,装饰器提供了一种结构化的、声明式的元编程能力,特别适合于在类和方法层面注入通用逻辑。而高阶函数则提供了更底层的、更灵活的函数组合能力,适用于任何函数。HOC 则是高阶函数在 React 组件层面的特定应用。没有绝对的好坏,只有最适合你当前场景的方案。关键在于理解它们的本质和适用边界,然后做出明智的选择。
以上就是JS 装饰器模式实战 - 使用 Decorators 增强类与方法的优雅方案的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号