Javascript 反模式
原文链接 https://ronghuaxueleng.github.io/2016/09/10/javascript%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-Javascript%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E2%80%94%E2%80%94%E5%8F%8D%E6%A8%A1%E5%BC%8F/
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。
什么是反模式
如果我们认为一种模式代表一种最佳实践,那么一种反模式就代表我们已经学到的教训。反模式这个术语是1995年由安德鲁·凯尼格在当年的11月C++报告中创造的,是受“四人组”所著《设计模式》一书的启发。在凯尼格的报告中,他提出反模式的两个概念:
描述一种针对某个特定问题的不良解决方案,该方案会导致糟糕的情况发生; 描述如何摆脱前述的糟糕情况以及如何创造好的解决方案
<!--more-->
反模式的由来
每一个设计问题都是以在两个实体之间实现平衡为开始的,即:问题的形式和它的上下文。形式是解决问题的方案;上下文定义该问题。
虽然设计模式很重要,但是理解反模式也同样重要。创建应用程序时,一个项目的声明周期就会以此为起点;一旦完成了初始版本,就需要进行维护。最终方案的质量好坏取决于技能水平和团队投入时间。
当然这里的好坏是在上下文中考虑的,如果一个“完美的”设计模式应用于错误的上下文中,那么它也可能是一个反模式。应用程序在进入生产环境并即将进入维护模式时会面临更大的挑战。之前没有研究过该应用程序的开发人员,在这样的系统上工作,可能会将不良设计意外地引入到项目中,如果说将不良实践创建为反模式,则能让开发人员有办法提前识别这些反模式,这样可以避免常见错误的发生。
总结
总的来说,反模式是一种值得记录的不良设计。Javascript中常见的反模式有很多,简单举几个例子:
- 在全局上下文中定义大量的变量污染全局命名空间。
- 向setTimeout或setInterval传递字符串,无意中触发eval( )的内部使用。
- 修改Object类的原型(这是一个特别不良的反模式)
- 以内联形式使用Javascript,它是不可改变的。
- 在使用document.createElement等原生DOM方法更适合的情况下使用document.write。多年来document.write一直都在被滥用,并有相当多的缺点,包括:如果在页面加载完成后执行document.write,它实际上会重写我们的页面,而documet.createElement则不会。
总之,了解反模式是成功的关键。一旦能够识别这种反模式,我们能重构代码来防止它们的出现,这样我们解决方案的总体质量就能立即得到改善。