装饰器--代码也要面子的

背景

当时在做用户埋点相关的，用户行为分析的时候，发现公司的ｕｉ组件，在标记上一些ｉｄ后，为了实现用户行为上报，由于上报数据，是基于被标记的控件，又由于被标记的时候，标错位置了，导致上报的信息不准，因此需要用到装饰器，统一对于组件进行标记定对，不用装饰器，就要一个个去修改组件源代码，既不方便，也是一种侵入式代码

核心点

那么先带着大家来回顾一下装饰器的定义： 本质上来讲就是一个函数，一个能增强原有方法，对象的功能

那么运用这个装饰器的原因是什么

从实际业务场景来看，如果你想去对某些类，函数，进行功能增强，从规范上来讲尽量不要用继承，优先去使用这个对象扩充 最大的优势在于在不修改原有代码的基础上进行功能增强

符合开放封闭原则：仅仅对现有功能进行扩展，新旧逻辑进行解耦

执行时机

是在编译时期 首先我举一个小例子

最终目的

如何非侵入式实现工程需求，为什么不用继承，因为耦合度太高 ``

function funcDecorator(target, name, descriptor) {
    let originalMethod = descriptor.value
    descriptor.value = function() {
    console.log('我是Func的装饰器逻辑')
    // 由于重新原函数丢失了this,这里的参数都是来源于被装饰的函数本身，而不是当前装饰器的函数
    return originalMethod.apply(this, arguments)
  }
  return descriptor
}

class Button {
    @funcDecorator
    onClick() { 
        console.log('我是Func的原有逻辑')
    }
}   

通过装饰器，在原因函数基础上增加了一个输出打印 更进一步的工程应用近期会更新