Decorator vs Proxy

Com Proxy o objeto real não sabe o que será executado pelo proxy. Já no decorator ele sabe porque a associação é explícita no seu código. Decorator altera o código original.

Indo além, contribuo com as seguintes dicas.

Você usa proxy quando não quiser poluir seu código com código estranho, inclusive anotações. Já o decorator fica evidente sua presença e você precisa da implementação do decorator ou terá problemas.

Porém, proxy consome mais memória do que decorator, pois decorator não cria uma nova instância.

Decorator é menos burocrático de se implementar do que proxy.

Proxy é mais flexível porque você pode cria-lo em runtime e aplica-lo onde quiser. Com decorator só onde você anotou antes no seu código ele será aplicado.

No final, é o bom senso do programador que escolherá entre um e outro.

Em JavaScript puro sem babel você faria assim

http://blog.alura.com.br/javascript-debounce-pattern-closure-e-duas-amigas/

Veja nesse meu post a implementação do debounce pattern.

Em JavaScript com babel é igual a TypeScript.

https://babeljs.io/docs/plugins/transform-decorators/

Você ainda pode usar decorator de classe para que o constructor da devolva um proxy em vez de fazer a associação manualnente. Como disse, é o problema e o bom senso do programador que ditará o que será feito.

Flavio, obrigado!

Já havia lido seu artigo no blog do Alura, porém não havia feito essa associação.

Para ilustrar, veja se é mais ou menos como fiz abaixo:

function logarTempoExecucao(fn) {
    return function() {
        const t1 = performance.now()

        fn()

        const t2= performance.now()
        console.log('Tempo de execução em s:', (t2 - t1) / 1000)
    }
}

testeDecorado = logarTempoExecucao(teste)
function teste() {
    for (i = 0; i <= 1000000000; i++) {}
    console.log('Contei até 1 bilhão')
}

testeDecorado()

Faz sentido?

Faz sim!

Obrigado!