闭包权威指南：JavaScript中的核心技术

下载需积分: 10 | PDF格式 | 6.85MB | 更新于2024-07-21 | 70 浏览量 | 举报

"Closure： The Definitive Guide 是一本由 Michael Bolin 编写的关于 JavaScript 闭包技术的专业书籍。本书详细介绍了 JavaScript 中的闭包概念及其应用，旨在为开发者提供全面的理解和指导。" 在 JavaScript 编程语言中，闭包（Closure）是一种至关重要的特性，它涉及到函数、作用域和内存管理等多个方面。闭包允许函数访问并操作其自身作用域内的变量，即使该函数已经执行完毕，这些变量仍然可以被保留。这在很多场景下非常有用，比如实现数据封装、模块化、异步操作等。闭包的基本原理是，当一个内部函数引用了外部函数的变量时，它会形成一个闭包，使得外部函数的作用域链在内部函数中得以保持。这使得内部函数可以在任何时候访问外部函数的局部变量，只要这个内部函数还存在。这种特性使得 JavaScript 能够实现动态作用域，而非静态作用域。在《Closure: The Definitive Guide》这本书中，作者 Michael Bolin 将深入探讨以下主题： 1. 闭包的概念和工作原理：解释什么是闭包，如何创建闭包，以及闭包与作用域的关系。 2. 作用域链：详述 JavaScript 的作用域规则，包括全局作用域、局部作用域以及函数作用域。 3. 变量生命周期：讨论变量的声明、初始化、作用域链的建立以及垃圾回收机制与闭包的关系。 4. 模块模式：利用闭包实现私有变量和方法，创建模块化的代码结构。 5. 闭包与内存管理：理解闭包如何影响内存占用，以及如何避免不必要的内存泄漏。 6. 闭包在异步编程中的应用：如回调函数、Promise 和 async/await 中闭包的使用。 7. IIFE（立即调用的函数表达式）：介绍如何使用闭包来创建独立的作用域。 8. 闭包和性能：讨论闭包可能带来的性能问题，以及优化策略。 9. 实战案例：通过实际代码示例展示闭包在各种实际场景下的应用。这本书适合已经有一定 JavaScript 基础的开发者阅读，帮助他们深入理解闭包这一复杂但强大的工具，从而提升编程技能。无论你是前端开发、后端开发还是移动开发，对闭包的深入理解都将对你的项目带来积极影响。

You’ll find answers to many of those specific questions throughout this book. But I

think the question that the book is most interested in (and rightly so) is about how to

make it easy to reuse code for Ajax apps. It spins off into a few other equally substantial

questions.

How do you share JavaScript code? How do you organize large amounts of common

JavaScript, often built for highly specialized tasks? How do you weigh one team’s need

for boatloads of new features and customizations against another team’s need to keep

the size of the JavaScript they’re sending to the user small?

The Closure Tools were designed to solve many of these problems. Maybe that’s un-

derstating the point. These problems are at the very core of their design. Many of the

tools were started by our friends on Gmail. Gmail began as a relatively modest Java-

Script app. Then they added more and more features, and watched it grow beyond any

hope of control or maintainability. Frederick P. Brooks, Jr., famously described large-

system programming as “a tar pit, and many great and powerful beasts have thrashed

violently in it.” In a language like JavaScript, a highly dynamic environment where

almost everything can be mutated and there’s no standard way to specify contracts

(type checking or otherwise), the tar is fast and can suck down even a small group of

developers.

The Closure Tools developers tried to bring “closure” to this mess. (I agree the pun is

terrible. It is not mine.) They followed strict idioms for namespacing code and defining

classes. They adopted ECMAScript 4’s type language for specifying contracts. The

compiler forced the developer to declare their variables, and emitted warnings for other

frowned-upon idioms. The Closure Tools, in short, tried to add some structure to the

language. Many engineering teams at Google found this structure useful, and built their

products on top of it.

A long time passed. The Closure Tools remained proprietary for years. This wasn’t

meant to be. Both the compiler and the libraries were always designed to be open source

projects. But more importantly, they were designed for building Google apps first, and

to be open source projects second. So releasing them publicly took a back seat to other

things.

Have you ever tried to publicly open up the code of a proprietary project? Several en-

gineers had tried to release Closure Compiler. They had all given up. It is surprisingly

difficult. There are two major parts. First, you have to release the code: port it to a

public build system like Apache Ant, remove all of its nonopen dependencies, and

rewrite any dependencies that you can’t remove. Second, you have to write documen-

tation: loads of documentation.

You can imagine how skeptical I was when Michael first came by my desk to talk about

making Closure Compiler an open source project. This was early 2009. By this point,

“publicly releasing Closure Compiler” was the sort of daunting chore that you’ve pro-

crastinated forever and a half. We’d work on it for a month, realize that we seemed no

xiv | Foreword

www.it-ebooks.info

Preface

JavaScript borrows many great ideas from other programming languages, but its most

unique, and perhaps most powerful, feature is that any code written in JavaScript can

run as-is in any modern web browser. This is a big deal, and it is unlikely to change

anytime soon.

As web browsers improve and become available on more devices, more applications

are being ported from desktop applications to web applications. With the introduction

of HTML5, many of these applications will be able to work offline for the first time. In

order to create a superior user experience, much of the logic that was previously done

on the server will also have to be available on the client. Developers who have written

their server logic in Java, Python, or Ruby will have to figure out how to port that server

logic to JavaScript. Tools like Google Web Toolkit, which translate Java to JavaScript

can help with this, though such tools are often clumsy because the idioms from one

programming language do not always translate smoothly into that of another. How-

ever, if your server code is written in JavaScript, this is not an issue.

I believe that the use of server-side JavaScript (SSJS) is just beginning. Previously, most

implementations of JavaScript were too slow to be considered a viable option for server

code. Fortunately, the recent competition among browser vendors to have the fastest

JavaScript engine makes that difference far less significant (http://shootout.alioth.debian

.org).

Because of the emerging support for offline web applications, it is compelling to write

both the client and the server in the same programming language to avoid the perils

associated with maintaining parallel implementations of the same logic. Because it is

extremely unlikely that all of the major browser vendors will adopt widespread support

for a new programming language, that will continue to force the client side of a web

application to be written in JavaScript, which in turn will pressure developers to write

their servers in JavaScript as well. This means that the size of the average JavaScript

codebase is likely to increase dramatically in the coming years, so JavaScript developers

will need better tools in order to manage this increased complexity. I see Closure as the

solution to this problem.

xvii

www.it-ebooks.info

Closure is a set of tools for building rich web applications with JavaScript, and brings

with it a new approach to writing JavaScript and maintaining large JavaScript applica-

tions. Each tool in the suite is designed to be used independently (so jQuery developers

can make use of the Closure Compiler and Closure Templates, even if they are not

interested in the Closure Library), but they are most effective when used together.

Many JavaScript toolkits today focus on DOM utilities and UI widgets. Such function-

ality is incredibly useful when building the interface for a web application, but the

emergence of SSJS will require an equivalent effort in building server-side JavaScript

libraries. There, the focus is likely to be on data structures and efficient memory usage,

both of which are already woven into the Closure framework.

I believe that Closure will play an important part in making web applications faster and

more reliable. As an active user of the Web, I have a vested interest in making sure this

happens. That’s why I had to write this book. Rather than document every API in

Closure, I have tried to provide detailed explanations for the most commonly used

APIs, particularly those that are unique to the Closure approach.

Indeed, learning Closure will change the way you develop JavaScript applications.

My Experiences with Closure

When I worked at Google from 2005 to 2009, I used Closure to help build Google

Calendar and Google Tasks. When the initial work on Calendar was done in 2005, only

the Compiler was available, and it was (and is) known internally as the JavaScript

Compiler. At the time, there were a number of common JavaScript utilities that teams

would copy from one another. This led to many forked versions, so improvements to

one copy did not propagate to the others.

Meanwhile, the JavaScript codebase for Gmail had grown so large and complex that

developers complained that it was too hard for them to add new features. This triggered

a rewrite of the Gmail client, which precipitated the development of the two other major

tools in the Closure suite: the Library and Templates. The Library was simply named

“Closure,” as it was a play on the programming construct used so frequently in Java-

Script, as well as the idea that it would bring “closure” to the nightmare that was

JavaScript development at Google.

Like many other JavaScript toolkits, the goal of Closure was to provide a comprehensive

cross-browser library. Instead of adopting an existing solution, such as Dojo, Google

decided to roll its own. By having complete control of its library, it could ensure that

the API would be stable and that the code would work with its (then) secret weapon:

the Closure Compiler. This made it possible to buck the trend established by libraries

like Prototype that encouraged the use of absurdly short function names. In Closure,

nondescript function names such as $ were eschewed in favor of more descriptive ones

because the Compiler would be responsible for replacing longer names with shorter

ones.

xviii | Preface

www.it-ebooks.info

剩余593页未读，继续阅读

qq_30039011

粉丝: 0

闭包权威指南：JavaScript中的核心技术

Closure The Definitive Guide

闭包权威指南] Closure：The Definitive Guide Michael Bolin

Closure工具完全指南

Google Closure工具套件入门指南

JavaScript闭包详解：权威指南

闭包权威解析：掌握JavaScript的核心概念

深入浅出JavaScript：多面教程与实用技巧

Python dis模块的深度学习：构建字节码模式识别系统（未来技术）

cole_02_0507.pdf

工程硕士开题报告：无线传感器网络路由技术及能量优化LEACH协议研究

最新资源