为什么不要直接在Object.prototype上定义方法
1个回答
2016-08-08 · 知道合伙人数码行家
huanglenzhi
知道合伙人数码行家
向TA提问 私信TA
知道合伙人数码行家
采纳数:117538
获赞数:517176
长期从事计算机组装,维护,网络组建及管理。对计算机硬件、操作系统安装、典型网络设备具有详细认知。
向TA提问 私信TA
关注
展开全部
考虑以下几点:
1、可靠性
当项目只有你一个人时,你想怎么改就怎么改,因为你很清楚他们。
当你的项目不止一个人时,就很容易出现冲突,并且你会为了解决这个冲突而花费更多的时间。
举个真实的例子:js红皮书的作者在雅虎工作时,因为同事更改了一个YAHOO.util.Event.stopEvent()方法,结果导致他花了几天的时间去解决这个问题,当好不容易解决了,更多的bug出现了,因为还有很多地方也都依赖于这个方法。所以他说了一句话:Don’t modify objects you don’t own
2、兼容性
不单单是上面的问题,你可能会更关心你的项目是否可以在将来使用。
吸取一下Prototype 的教训。
大概意思就是说Prototype写了一个很好的方法,后来大家都觉得好,所以JS在原生的方法上也加了这个。但是不幸的是,prototype返回的是Array,JS返回的是NodeList。那在原生方法没出现之前这句代码document.getElementsByClassName('myclass').each(doSomething)可以好好的执行,但是原生方法出来后,NodeList并没有each方法…所以prototype就悲剧了…
3、如果所有人都改呢?这个问题的严重性应该不用说了…
所以用Nicholas C.Zakas的一句话做总结:Don’t modify objects you don’t own。
1、可靠性
当项目只有你一个人时,你想怎么改就怎么改,因为你很清楚他们。
当你的项目不止一个人时,就很容易出现冲突,并且你会为了解决这个冲突而花费更多的时间。
举个真实的例子:js红皮书的作者在雅虎工作时,因为同事更改了一个YAHOO.util.Event.stopEvent()方法,结果导致他花了几天的时间去解决这个问题,当好不容易解决了,更多的bug出现了,因为还有很多地方也都依赖于这个方法。所以他说了一句话:Don’t modify objects you don’t own
2、兼容性
不单单是上面的问题,你可能会更关心你的项目是否可以在将来使用。
吸取一下Prototype 的教训。
大概意思就是说Prototype写了一个很好的方法,后来大家都觉得好,所以JS在原生的方法上也加了这个。但是不幸的是,prototype返回的是Array,JS返回的是NodeList。那在原生方法没出现之前这句代码document.getElementsByClassName('myclass').each(doSomething)可以好好的执行,但是原生方法出来后,NodeList并没有each方法…所以prototype就悲剧了…
3、如果所有人都改呢?这个问题的严重性应该不用说了…
所以用Nicholas C.Zakas的一句话做总结:Don’t modify objects you don’t own。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询