发现一种反模式写法，问问大家的意见

[autoxbc]

有如下一小段代码，能否发现这里有什么问题？

const math = {
    sin(val){
        return Math.sin(val);    
    },
    cos(val){
        return Math.cos(val);    
    },
    tan(val){
        const sin = this.sin ;
        const cos = this.cos ;
        return sin(val)/cos(val);    
    },
};

一个粗心的程序员可能会这么续写

const { sin , cos , tan } = math ;
console.log( tan(.5) );

这里就会报错了，因为 tan 方法内部需要的 this 对象在解构赋值的时候丢失了。要想正确使用，必须把代码写成这样的丑陋形式

let { sin , cos , tan } = math ;
[ sin , cos , tan ] = [ sin , cos , tan ].map( e => e.bind(math) );
console.log( tan(.5) );

不过，其实只要在开始的时候，把这两行

const sin = this.sin ;
const cos = this.cos ;

写成

const sin = math.sin ;
const cos = math.cos ;

这样，就消除了隐患。显然，对于 tan 方法，动态绑定 this 对象是没有意义的，因为这个值既不会也不允许改变

总结一下就是，this 是针对动态绑定需求设计的，如果没有这个需求，就不要强行使用，哪怕表面上看上去很优雅

[tommyZZM]

正确的做法是这样。

```
function sin(val) {
return Math.sin(val);
}

function cos(val) {
return Math.cos(val);
}

function tan(val) {
return sin(val)/cos(val);
},

const math = {
sin, cos, tan
};
```

什么`this`啊, `Function.prototype.bind`啊其实都是糟粕，能不用就不用

[tommyZZM]

有一个很核心的思路是，尽可能降低函数对外部环境的隐式依赖，同时函数执行时不应该隐式地影响外部环境。

函数之间的关联应该是通过参数的传入联系起来的。

使用了 this 实际上就依赖了调用环境上下文，是一种不好的做法。

[no1xsyzy]

@ChefIsAwesome 对啊，这个明显是函数式写法啊，为什么要加 this

[no1xsyzy]

“论如何同时激怒两拨人”
写一个函数式的代码，并且用上 this 并开始谈论对象。

----

const sin = this.sin ;
const cos = this.cos ;

这两行直接删去即可。

[66beta]

js 严格来讲没有“对象”
class 也只是模拟，将来指不定就成了糟粕

[marcong95]

@66beta js 是没有类吧，js 无处不在的对象，你总不能说那是个哈希表吧

[autoxbc]

@no1xsyzy #24 删去能运行刚好是碰运气，后面写成 const { tan } = math 不引入 sin cos 就无效了

[66beta]

@marcong95 你说的对，我话不严谨，是 OOP 里的 oo

[mskf]

你是说静态方法只能在静态方法中被引用吗

[rabbbit]

[royzxq]

意义不明。

[zealot0630]

楼主对 OO 的理解有严重问题，OO 设计中，成员函数是放在 prototype 或 meta 里面，而不是对象里面。

[cyssxt]

math 本来就封装好的 为什么再来一次

[nullcc]

说 JS this 恶心的应该是那些完全不理解 JS 对象模型的人

[zealot0630]

@nullcc

JS 的 this 是恶心，这点没得洗，都是历史遗留的包袱。

this 现在大部分情况作为函数的一个额外参数使用，而不是用于调用成员函数，访问成员变量。