Skip to content

Commit d560b40

Browse files
committed
Finish translating Service-Singleton section
1 parent b93debb commit d560b40

File tree

1 file changed

+40
-6
lines changed

1 file changed

+40
-6
lines changed

i18n/README-zh-cn.md

Lines changed: 40 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@
1818
* [Services](#services-1)
1919
* [单例模式 (Singleton)](#singleton)
2020
* [工厂方法模式 (Factory Method)](#factory-method)
21-
* [修饰模式](#decorator)
21+
* [修饰模式 (Decorator)](#decorator)
2222
* [外观模式](#facade)
2323
* [代理模式](#proxy)
2424
* [Active Record](#active-record)
@@ -171,12 +171,12 @@ All the custom elements, attributes, comments or classes could be recognized as
171171

172172
### Scope
173173

174-
在 AngularJS 中,scope 是一个开放给 partial 的 JavaScript 对象。Scope 可以包含不同的属性 - 基本数据 (primitives)、对象和函数。所有归属于 scope 的函数都可以通过解析该 scope 所对应 partial 中的 AngularJS 表达式来执行,也可以由任何构件直接呼叫该函数,which keeps reference to the scope。附属于 scope 的数据可以通过使用合适的 *directives* 来绑定到视图 (view) 上,如此所有 partial 中的修改都会映射为某个 scope 属性的变化,反之亦然。
174+
在 AngularJS 中,scope 是一个开放给 partial 的 JavaScript 对象。Scope 可以包含不同的属性 - 基本数据 (primitives)、对象和函数。所有归属于 scope 的函数都可以通过解析该 scope 所对应 partial 中的 AngularJS 表达式来执行,也可以由任何构件直接调用该函数,which keeps reference to the scope。附属于 scope 的数据可以通过使用合适的 *directives* 来绑定到视图 (view) 上,如此所有 partial 中的修改都会映射为某个 scope 属性的变化,反之亦然。
175175
<!--
176176
In AngularJS scope is a JavaScript object, which is exposed to the partials. The scope could contain different properties - primitives, objects or methods. All methods attached to the scope could be invoked by evaluation of AngularJS expression inside the partials associated with the given scope or direct call of the method by any component, which keeps reference to the scope. By using appropriate *directives*, the data attached to the scope could be binded to the view in such a way that each change in the partial will reflect a scope property and each change of a scope property will reflect the partial.
177177
-->
178178

179-
AngularJS 应用中的 scope 还有另一个重要的特质,即它们都被连接到一条原型链 (prototypical chain) 上 (除了那些被表明为*独立 (isolated)* 的 scope)。在这种方式中,任何子 scope 都能呼叫属于其父母的函数,因为这些函数是该 scope 的直接或间接原型 (prototype) 的属性。
179+
AngularJS 应用中的 scope 还有另一个重要的特质,即它们都被连接到一条原型链 (prototypical chain) 上 (除了那些被表明为*独立 (isolated)* 的 scope)。在这种方式中,任何子 scope 都能调用属于其父母的函数,因为这些函数是该 scope 的直接或间接原型 (prototype) 的属性。
180180
<!--
181181
Another important characteristics of the scopes of any AngularJS application is that they are connected into a prototypical chain (except scopes, which are explicitly stated as *isolated*). This way any child scope will be able to invoke methods of its parents since they are properties of its direct or indirect prototype.
182182
-->
@@ -328,6 +328,7 @@ myModule.service('Developer', function () {
328328
};
329329
});
330330
```
331+
331332
Service 可以被注入到任何支持依赖注入机制的构件中,例如 controller、其它 service、filter 和 directive。
332333
<!--
333334
The service could be injected inside any component, which supports dependency injection (controllers, other services, filters, directives).
@@ -340,7 +341,7 @@ function MyCtrl(Developer) {
340341
}
341342
```
342343

343-
## AngularJS 模式
344+
## <a name='angularjs-patterns'>AngularJS 模式</a>
344345

345346
我们将在接下来的几节中探讨传统的设计和架构模式是如何在 AngularJS 的各个构件中组合实现的。并在最后一节讨论使用 AngularJS (或其它框架) 开发单页应用程序时常用的架构模式。
346347
<!--
@@ -351,24 +352,44 @@ In the last chapter we are going to take a look at some architectural patterns,
351352

352353
### Services
353354

354-
#### 单例模式 (Singleton)
355+
#### <a name='singleton'>单例模式 (Singleton)</a>
355356

357+
>单例模式是一种软件设计模式。在应用这个模式时,单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象,这样有利于我们协调系统整体的行为。如果系统在仅有一个对象或者有限个数的对象实例的环境中运行更加高效,也时常被归属为单例模式概念。
358+
<!--
356359
>The singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects.
360+
-->
357361

362+
以下 UML 图展示了单例设计模式。
363+
<!--
358364
In the UML diagram bellow is illustrated the singleton design pattern.
365+
-->
359366

360367
![Singleton](https://rawgit.com/mgechev/angularjs-in-patterns/master/images/singleton.svg "Fig. 1")
361368

369+
AngularJS 会按照以下算法来解决构件所需要的依赖关系:
370+
<!--
362371
When given dependency is required by any component, AngularJS resolves it using the following algorithm:
372+
-->
363373

374+
- 提取所依赖组件的名称,并查询哈希表 (该表是定义在一个闭包中,所以外部不可见)。
375+
- 如果此依赖组件已经存在于应用中,AngularJS 会在需要的时候以参数的形式将其传递给对应的构件。
376+
- 如果所依赖的组件不存在:
377+
- AngularJS 首先会调用其提供者的生成函数,如 `$get`。值得注意的是,创建此依赖组件的实例时,可能会对算法内容进行递归调用,以解决该组件本事的依赖关系。
378+
- AngularJS 然后会将其缓存在上面提到的哈希表中。
379+
- AngularJS 最后会在需要的时候将其传递给对应组件。
380+
<!--
364381
- Takes its name and makes a lookup at a hash map, which is defined into a lexical closure (so it has a private visibility).
365382
- If the dependency exists AngularJS pass it as parameter to the component, which requires it.
366383
- If the dependency does not exists:
367384
- AngularJS instantiate it by calling the factory method of its provider (i.e. `$get`). Note that instantiating the dependency may require recursive call to the same algorithm, for resolving all the dependencies required by the given dependency. This process may lead to circular dependency.
368385
- AngularJS caches it inside the hash map mentioned above.
369386
- AngularJS passes it as parameter to the component, which requires it.
387+
-->
370388

389+
以 AngularJS 源代码中 `getService` 函数的实现为例:
390+
<!--
371391
We can take better look at the AngularJS' source code, which implements the method `getService`:
392+
-->
372393

373394
```JavaScript
374395
function getService(serviceName) {
@@ -394,14 +415,27 @@ function getService(serviceName) {
394415
}
395416
```
396417

418+
由于每个 service 只会被实例化一次,我们可以将每个 service 看成是一个单例。缓存则可以被认为是单例管理器。这里与上面展示的 UML 图有微小的区别,那就是我们并不将单例的静态私有的 reference 保存在其构造 (constructor) 函数中,而是将 reference 保存在单例管理器中 (以上代码中的 `cache`)。
419+
<!--
397420
We can think of each service as a singleton, because each service is instantiated no more than a single time. We can consider the cache as a singleton manager. There is a slight variation from the UML diagram illustrated above because instead of keeping static, private reference to the singleton inside its constructor function, we keep the reference inside the singleton manager (stated in the snippet above as `cache`).
421+
-->
398422

423+
如此 service 实际还是单例,但并不是以传统单例设计模式的方法所实现。相比之下,这种方式有如下优点:
424+
<!--
399425
This way the services are actually singletons but not implemented through the Singleton pattern, which provides a few advantages over the standard implementation:
426+
-->
400427

428+
- 增强代码的可测试性
429+
- 控制单例对象的创建 (在本节例子中,IoC 容器通过懒惰式单例实例化方式帮我们进行控制)
430+
<!--
401431
- It improves the testability of your source code
402432
- You can control the creation of singleton objects (in our case the IoC container controls it for us, by instantiating the singletons lazy)
433+
-->
403434

435+
对于更深入的讨论,可以参考 Misko Hevery 在 Google Testing blog 上的[文章](http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html)
436+
<!--
404437
For further discussion on this topic Misko Hevery's [article](http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html) in the Google Testing blog could be considered.
438+
-->
405439

406440
#### 工厂方法模式 (Factory Method)
407441

@@ -493,7 +527,7 @@ There are a few benefits of using the factory method pattern in this case, becau
493527
- Resolving all the dependencies required by the component
494528
- The number of instances the given component is allowed to have (for services and filters only a single one but multiple for the controllers)
495529

496-
#### Decorator
530+
#### <a name='decorator'>修饰模式 (Decorator)</a>
497531

498532
>The decorator pattern (also known as Wrapper, an alternative naming shared with the Adapter pattern) is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.
499533

0 commit comments

Comments
 (0)