Guice2.0 beta 紹介記事の翻訳(6)

原文：IBM Developer : Sorry, that page no longer exists
訳１：Guice2.0 beta 紹介記事の翻訳(1) - 山本大の日記
訳２：Guice2.0 beta 紹介記事の翻訳(2) - 山本大の日記
訳３：Guice2.0 beta 紹介記事の翻訳(3) - 山本大の日記
訳４：Guice2.0 beta 紹介記事の翻訳(4) - 山本大の日記
訳５：Guice2.0 beta 紹介記事の翻訳(5) - 山本大の日記

スコープ(Scopes)

By default, Guice creates a new instance of each dependency you ask for. If your objects are lightweight, this policy will serve you well. However, if you have an expensive-to-create dependency, you may want to share an instance among several clients. In Listing 19, HeroModule binds the HeavyWaterRefinery as a singleton:

デフォルトでは、Guiceは問い合わせがあるたびに、それぞれの依存性の新しいインスタンスを生成します。もし、オブジェクトが軽量なものならこのポリシーで良いでしょう。しかし、もし、とても生成が重い依存性があるなら、インスタンスをいくつかのクライアントに渡って共有したいと思うことでしょう。
リスト19では、ヒーローモジュールが重水精製装置(HeavyWaterRefinery)をシングルトンとしてバインドしています。

リスト19.重水精製装置をシングルトンでバインドする。(HeavyWaterRefinery bound as a singleton)

public class HeroModule implements Module {
  public void configure(Binder binder) {
    //...
    binder.bind(FuelSource.class)
      .to(HeavyWaterRefinery.class).in(Scopes.SINGLETON);
  }
}

Are singletons evil?
If you search the Web for "singletons are evil," you'll find plenty of blog posts, articles, and rants about singletons. It turns out that there's a difference between an "application singleton" and a "JVM singleton" (which is the kind commentators rail against). The JVM singleton enforces its "singletonness" by using linguistic tricks and by forcing clients to reference it using a static reference. An application singleton, on the other hand, doesn't enforce this policy. Another layer (for example, Guice) enforces that one instance of the class exists per application. Client code doesn't know about this rule, and this keeps the design flexible and tests easy to write.
This means Guice will keep the refinery around, and whenever another instance requires a fuel source, Guice will inject the same refinery. This prevents more than one refinery from starting up in the application.
Guice offers you an option when you select scopes. You can configure them using the binder, or you can annotate the dependency directly, as in Listing 20:

シングルトンは悪でしょうか？Webで"シングルトンは悪だ（singletons are evil)"と検索すると、シングルトンに対する罵詈雑言を書いた沢山の記事やブログが見つかることでしょう。（熱心な抗議解説者によると）それらは結局、アプリケーションシングルトンと、JVMシングルトンとの違いであるとわかります。
JVMシングルトンは、言葉のトリックによって"シングルトン性"が強調されてしまっています。また参照を得るために静的な参照を使うことを強制するという面が強調されすぎです。
アプリケーションシングルトンは、これとは異なりこういったポリシーを強制しません。ほかのレイヤー（例えばGuiceのような）は、クラスの配置されたアプリケーションに対してインスタンスが一つであることを強制します。
クライアントコードは、このルールについて知る必要はありませんし、柔軟な設計とテストコードの書きやすさについても保ったままなのです。
これは、Guiceが精製所を保持しておくことを表しています。燃料を得るために他のインスタンスが要求してきたときはいつでも、Guiceは同じ精製所からインジェクトするということです。アプリケーションが起動したときに精製所を作っておけば、1つ以上のインスタンスが作られることを抑制できます。
Guiceはスコープを選択するときの選択肢を提供します。バインダーをつかってそれらを設定することができるのです。または、依存クラスに対して直接アノテートすることもできます。リスト20ではその様子を表します。

リスト20.代わりに、アノテーションによってスコープを選択する(Choosing scope with an annotation instead)

@Singleton
public class HeavyWaterRefinery implements FuelSource {...}

Guice provides Singleton scope out of the box, but it allows you to define your own scopes if you wish. As an example, the Guice servlet package supplies two additional scopes: Request and Session, which serve up a unique instance of your class per servlet request and servlet session.

Guiceはシングルトンスコープを独創的な方法で提供します。しかし、これによって望むなら自分用の独自スコープを定義することができるようになります。
例えば、Guiceサーブレットパッケージは、リクエストとセッションという2つの追加スコープを提供しています。これらは、サーブレットリクエストやサーブレットセッションごとに1つのインスタンスを提供します。