You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
182
182
-->
@@ -328,6 +328,7 @@ myModule.service('Developer', function () {
328
328
};
329
329
});
330
330
```
331
+
331
332
Service 可以被注入到任何支持依赖注入机制的构件中,例如 controller、其它 service、filter 和 directive。
332
333
<!--
333
334
The service could be injected inside any component, which supports dependency injection (controllers, other services, filters, directives).
>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
+
-->
357
361
362
+
以下 UML 图展示了单例设计模式。
363
+
<!--
358
364
In the UML diagram bellow is illustrated the singleton design pattern.
- Takes its name and makes a lookup at a hash map, which is defined into a lexical closure (so it has a private visibility).
365
382
- If the dependency exists AngularJS pass it as parameter to the component, which requires it.
366
383
- If the dependency does not exists:
367
384
- 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.
368
385
- AngularJS caches it inside the hash map mentioned above.
369
386
- AngularJS passes it as parameter to the component, which requires it.
387
+
-->
370
388
389
+
以 AngularJS 源代码中 `getService` 函数的实现为例:
390
+
<!--
371
391
We can take better look at the AngularJS' source code, which implements the method `getService`:
392
+
-->
372
393
373
394
```JavaScript
374
395
functiongetService(serviceName) {
@@ -394,14 +415,27 @@ function getService(serviceName) {
394
415
}
395
416
```
396
417
418
+
由于每个 service 只会被实例化一次,我们可以将每个 service 看成是一个单例。缓存则可以被认为是单例管理器。这里与上面展示的 UML 图有微小的区别,那就是我们并不将单例的静态私有的 reference 保存在其构造 (constructor) 函数中,而是将 reference 保存在单例管理器中 (以上代码中的 `cache`)。
419
+
<!--
397
420
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
+
-->
398
422
423
+
如此 service 实际还是单例,但并不是以传统单例设计模式的方法所实现。相比之下,这种方式有如下优点:
424
+
<!--
399
425
This way the services are actually singletons but not implemented through the Singleton pattern, which provides a few advantages over the standard implementation:
426
+
-->
400
427
428
+
- 增强代码的可测试性
429
+
- 控制单例对象的创建 (在本节例子中,IoC 容器通过懒惰式单例实例化方式帮我们进行控制)
430
+
<!--
401
431
- It improves the testability of your source code
402
432
- You can control the creation of singleton objects (in our case the IoC container controls it for us, by instantiating the singletons lazy)
433
+
-->
403
434
435
+
对于更深入的讨论,可以参考 Misko Hevery 在 Google Testing blog 上的[文章](http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html)。
436
+
<!--
404
437
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
+
-->
405
439
406
440
#### 工厂方法模式 (Factory Method)
407
441
@@ -493,7 +527,7 @@ There are a few benefits of using the factory method pattern in this case, becau
493
527
- Resolving all the dependencies required by the component
494
528
- The number of instances the given component is allowed to have (for services and filters only a single one but multiple for the controllers)
495
529
496
-
#### Decorator
530
+
#### <aname='decorator'>修饰模式 (Decorator)</a>
497
531
498
532
>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.
0 commit comments