《JavaScript设计模式》的原文摘录

  • 模式是一种可复用的解决方案,可用于解决软件设计中遇到的常见问题. 另一种模式的方式是将解决问题的方式制作成模板,并且这些模板可用于多种不同的情况。 ... 设计模式的三大好处: 模式是已经验证的解决方案。 模式很容易被复用。 模式富有表达力。 模式的其他优点: 复用模式有助于防止在应用程序开发过程中小问题引发大问题。 模式可以通过提供通用的解决方案,并且其记录方式不需要与某个特定问题挂钩。 某些模式确实能够通过避免代码复用来减少代码的总体资源占用量。 模式添加到开发人员的词汇中,会使沟通更快速。 经常使用的模式可以逐步改进,因为其他开发人员使用这些模式后总结的共同经验又贡献给了设计模式社区。 (查看原文)
    飞翔的鱼 2013-12-09 09:00:23
    —— 引自第2页
  • 优秀的模式: 解决特殊问题; 没有显而易见的解决方案。解决问题的技术基本来自众所周知的基本原则。最好的设计模式通常会间接的提供解决问题的方案——这被认为是解决与设计相关的最具用挑战性问题的必要方法。 描述业经验证的概念; 描述一种关系。 成为有效模式的其中一个附加要求是,它们展示一些反复出现的现象。这通常可以限定在至少三个关键领域中,被称为三法则,使用该规则重现,则必须证明: 适合性 实用性 适用性 (查看原文)
    飞翔的鱼 2013-12-09 09:21:48
    —— 引自第6页
  • JavaScript中的反模式示例如下: 在全局上下文中定义大量的变量污染全局命名空间。 向setTimeOut或setTimeInterval传递字符串,而不是函数,这会触发eval()的内部使用。 修改Object类的原型(这是一个特别不好的反模式)。 以内联形式使用JavaScript,他是不可改变的。 在使用document.createElement等原生DOM方法更合适的情况下使用document.write。多年以来document.write一直都是在被严重滥用,并有相当多的缺点,包括:如果在页面加载完成后执行document.write,它实际上会重写我们所在的页面,而document.createElement则不会...document.write也无法与xhtml相适,这是选择像document.createElement这样更为DOM友好的方法比较有利的另一个原因。 (查看原文)
    飞翔的鱼 2013-12-09 21:50:06
    —— 引自第14页
  • 创建型设计模式、结构型设计模式、行为设计模式 (查看原文)
    飞翔的鱼 2013-12-09 22:05:12
    —— 引自第15页
  • JS中实现Module的方法: 对象字面量表示法:对象字面量不需要使用new运算符进行实例化,但不能用在一个语句的开头,因为开始的可能解读为一个块的开始。 Module模式:Module模式最初被定义为一种在传统软件工程中为类提供私有和公有封装的方法。在JS中,Module模式用于进一步模拟类的概念,通过这种方式,能够使一个单独的对象拥有公有/私有方法和变量,从而屏蔽来自全局作用域的特殊部分。产生的结果是:函数名与页面上其他脚本定义的函数冲突的可能性降低。 AMD模块 CommonJS模块 ECMAScript Harmony模块 Module模式的缺点: 1)由于我们访问公有和私有成员的方式不同,当我们想改变可见性时,实际上我们需要修改每一个曾经使用过该成员的地方。 2)无法给私有成员创建自动化单元测试,bug需要修正补丁时会增加额外的复杂性。为私有方法打补丁是不可能的。相反,我们必须覆盖所有与有bug的私有方法进行交互的公有方法。 3)开发人员无法轻易的扩展私有方法,记住私有方法并不像它们最初显现出来的那么灵活。 (查看原文)
    飞翔的鱼 2013-12-09 22:06:04
    —— 引自第20页
  • If you haven't come across concrete classes before, they are best explained in terms of class-based programming languages and are related to the idea of abstract classes. An abstract class defines an interface, but doesn't necessarily provide implementations for all of its member functions. It acts as a base class from which others are derived. A derived class which implements the missing functionality is called a concrete class (you may find these concepts familiar if you're read about the Decorator or Prototype patterns). (查看原文)
    北公爵 2014-12-15 18:11:52
    —— 引自第54页
  • When To Use The Factory Pattern The Factory pattern can be especially useful when applied to the following situations: • When your object's setup requires a high level of complexity • When you need to generate different instances depending on the environment • When you're working with many small objects that share the same properties • When composing classes with instances of other classes that need only satisfy an API contract (aka, duck typing) to work. This is useful for decoupling. (查看原文)
    北公爵 2014-12-17 17:52:00
    —— 引自第59页
  • Decorators Decorators are used when it's necessary to delegate responsibilities to an object where it doesn't make sense to subclass it. A common reason for this is that the number of features required demand for a very large quantity of subclasses. The decorator pattern isn't heavily tied to how objects are created but instead focuses on the problem of extending their functionality. Rather than just using inheritance, where we're used to extending objects linearly, we work with a single base object and progressively add decorator objects which provide the additional capabilities. The idea is that rather than subclassing, we add (decorate) properties or methods to a base object so its a little more streamlined. (查看原文)
    北公爵 2014-12-23 15:36:01
    —— 引自第63页
  • James Padolsey previously wrote a post called '76 bytes for faster jQuery' where he reminds us of an important point: every time jQuery fires off a callback, regardless of type (filter, each, event handler), you're able to access the function's context (the DOM element related to it) via the this keyword. Unfortunately, many of us have become used to the idea of wrapping this in $() or jQuery(), which means that a new instance of jQuery is constructed every time. Rather than doing this: (查看原文)
    北公爵 2014-12-30 17:41:59
    —— 引自第77页
  • Now with respect to redundant wrapping, where possible with jQuery's utility methods, it's better to use jQuery.N as opposed to jQuery.fn.N where N represents a utility such as each. Because not all of jQuery's methods have corresponding single-node functions, Padolsey devised the idea of jQuery.single. The idea here is that a single jQuery object is created and used for each call to jQuery.single (effectively meaning only one jQuery object is ever created). The implementation for this can be found below and is a flyweight as we're consolidating multiple possible objects into a more central singular structure. (查看原文)
    北公爵 2014-12-30 17:44:13
    —— 引自第78页
  • An example of this in action with chaining is: (查看原文)
    北公爵 2014-12-30 17:44:13
    —— 引自第78页
  • Templating It has long been considered (and proven) a performance bad practice to manually create large blocks of HTML markup in-memory through string concatenation. Developers doing so have fallen prey to inperformantly iterating through their data, wrapping it in nested divs and using outdated techniques such as document.write to inject the 'template' into the DOM. As this typically means keeping scripted markup inline with your standard markup, it can quickly become both difficult to read and more importantly, maintain such disasters, especially when building non-trivially sized applications. JavaScript templating solutions (such as Handlebars.js and Mustache) are often used to define templates for views as markup (either stored externally or within script tags with a custom type - ... (查看原文)
    北公爵 2015-01-29 11:02:27
    —— 引自第84页