面试题：TypeScript参数装饰器与类方法结合应用

实现参数装饰器验证参数类型约束：

function validateNumberGreaterThanZero(target: Object, propertyKey: string, parameterIndex: number) {
    return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        const originalMethod = descriptor.value;
        descriptor.value = function (...args: any[]) {
            const paramValue = args[parameterIndex];
            if (typeof paramValue!== 'number' || paramValue <= 0) {
                throw new Error(`The parameter at index ${parameterIndex} must be a number greater than 0.`);
            }
            return originalMethod.apply(this, args);
        };
        return descriptor;
    };
}

class MyClass {
    @validateNumberGreaterThanZero
    myMethod(@validateNumberGreaterThanZero num: number, otherParam: string) {
        console.log(`Number: ${num}, String: ${otherParam}`);
    }
}

const instance = new MyClass();
try {
    instance.myMethod(5, 'test');
    // instance.myMethod(-1, 'test'); // 会抛出异常
} catch (error) {
    console.error(error.message);
}

参数装饰器在处理复杂业务逻辑验证时的优势：
- 代码复用性高：可以将相同的验证逻辑应用到不同类的不同方法的参数上，避免在每个方法中重复编写验证代码。例如，多个方法都需要验证某个数字参数大于0，只需要定义一次validateNumberGreaterThanZero装饰器并应用到相应参数上。
- 关注点分离：业务逻辑和验证逻辑分开，使得代码结构更清晰。业务方法只专注于自身的功能实现，而验证逻辑通过装饰器来处理，提高了代码的可维护性。
- 灵活性：可以根据需要灵活地添加或移除验证逻辑。如果某个方法不再需要特定的验证，只需要移除对应的参数装饰器即可。
参数装饰器在处理复杂业务逻辑验证时的局限性：
- 作用范围有限：参数装饰器只能在方法调用时进行验证，无法在类实例化等其他场景进行验证。例如，如果希望在创建类实例时就验证某些参数，参数装饰器无法直接做到。
- 性能开销：对于频繁调用的方法，每次调用都要经过装饰器中的验证逻辑，可能会带来一定的性能开销。特别是当验证逻辑复杂时，这种开销可能会比较明显。
- 调试困难：当验证逻辑出现问题时，由于装饰器的逻辑相对独立，并且可能在多个地方复用，调试起来可能比直接在方法内部编写验证逻辑更困难，需要花费更多时间定位问题所在。

面试题：TypeScript参数装饰器与类方法结合应用

知识考点

面试题答案