| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| 我々はいかなる形態でありともに仕事をしたいと思う。 | 我々はいかなる形態であっても、共に仕事をしたいと思う。 |
| Line 30: | Line 30: |
|
1. You only need to use annotations when a binding type alone isn't sufficient. 1. You can reuse the same annotation type across multiple bindings (@Transactional for example). 1. Annotations can have attributes with values. You can bind each set of values separately to the same type if you like. |
1. 一つの型についてのバインディングが一つでは不十分な場合にだけアノテーションが必要になる。 1. 複数のバインディングで、同じアノテーションタイプを再利用することができる(例えば@Transactional)。（訳注：？） 1. アノテーションは値付のアトリビュートを持つことができる。望むならそれぞれの値セットを一つのタイプについて別々にバインドすることができる（訳注：？）。 |
| Line 34: | Line 34: |
| Spring supports two polar configuration styles: explicit configuration and auto-wiring. Explicit configuration is verbose but maintainable. Auto-wiring is concise but slow and not well suited to non-trivial applications. If you have 100s of developers and 100s of thousands of lines of code, auto-wiring isn't an option. Guice uses annotations to support a best-of-both-worlds approach which is concise but explicit (and maintainable). |
Springは二つの正反対なコンフィギュレーションスタイルを持つ。 明示的なコンフィギュレーションとオートワイアリングである。 明示的コンフィギュレーションは冗長であるがメンテナンスしやすい。 オートワイヤリングは手軽だが遅い上、比較的大きなアプリにはうまく適合しない。 もし、100人の開発者による数十万行のコードであれば、オートワイヤリングは選択できない。 Guiceはアノテーションを使うことにより、二つの世界のベストなアプローチをサポートすることができる。 つまり、手軽でかつ明示的（そしてメンテナンスしやすい）である。 |
| Line 36: | Line 42: |
| Some critics have tried to find an analog to Spring's XML (or new Java-based configuration) in Guice. Most times, there isn't any, but sometimes you can't use annotations, and you need to manually wire up an object (a 3rd party component for example). When this comes up, you write a custom provider. A custom provider adds one level of indirection to your configuration and is roughly 1:1 with Spring's XML in complexity. The remaining majority of the time, you'll write significantly less code. |
Guiceに、SpringのXML（あるいは新しいJavaベースのコンフィギュレーション）との類似性を見出そうとする評論家もいる。 Most times, there isn't any, but sometimes you can't use annotations, and you need to manually wire up an object (a 3rd party component for example). When this comes up, you write a custom provider. A custom provider adds one level of indirection to your configuration and is roughly 1:1 with Spring's XML in complexity. The remaining majority of the time, you'll write significantly less code. |
Springとの比較
Rod JohnsonによるSpringフレームワークはJava-DI界で大人気である。 最初のDIフレームワークとは言わないまでも、DIのパイオニアであり、DIをメインフレームにした功労者と言えるだろう。 Springが無ければGuiceも（少なくともこんなに早くには）存在しなかっただろう。
GuiceとSpringは直接的には競合しない。 Springは総合的なスタックであり、GuiceはDIに特化している。 そうであっても、人々の最初の質問は「GuiceとSpringの違いは？」である。 何度も熱弁をふるうよりも、この避けがたい質問に一度だけ答えておくのがよいだろう。
GuiceチームはSpring開発者やコミュニティ、その姿勢に多大なる尊敬の念を持つことをまず言わせてもらいたい。 我々はいかなる形態であっても、共に仕事をしたいと思う。 実は1.0のリリースの六ヶ月前に、数人のコアなSpring開発者に内密にソースまで公開したのである。
さて、さっさと本題に入ろう。GuiceとSpringがどのように違うのか？
GuiceはSpringの焼き直しなどではない。 GuiceはGoogleの（いかなる意味でも）最も大きなアプリケーション「アドワーズ」のユースケースから誕生した。 我々は自問自答した、このアプリを前進させるために、本当に欲しいものは何かと。 Guiceが我々の答えをもたらしたのである。
Guiceは全面的にアノテーションとジェネリックスを取り入れている。 それゆえ、オブジェクトをワイアリング、テストするための労力が計れる程度には減少する。 Guiceは、エラーになりがちでリファクタリングに不都合な文字列識別子の代わりにアノテーションを使用できることを証明した。
新しいユーザは多くのアノテーションが手に負えなくなることを恐れる場合がある。 大丈夫、Springアプリケーションで使う文字列識別子と同程度のアノテーションにしかGuiceではならない。
- 一つの型についてのバインディングが一つでは不十分な場合にだけアノテーションが必要になる。
- 複数のバインディングで、同じアノテーションタイプを再利用することができる(例えば@Transactional)。（訳注：？）
- アノテーションは値付のアトリビュートを持つことができる。望むならそれぞれの値セットを一つのタイプについて別々にバインドすることができる（訳注：？）。
Springは二つの正反対なコンフィギュレーションスタイルを持つ。 明示的なコンフィギュレーションとオートワイアリングである。 明示的コンフィギュレーションは冗長であるがメンテナンスしやすい。 オートワイヤリングは手軽だが遅い上、比較的大きなアプリにはうまく適合しない。 もし、100人の開発者による数十万行のコードであれば、オートワイヤリングは選択できない。 Guiceはアノテーションを使うことにより、二つの世界のベストなアプローチをサポートすることができる。 つまり、手軽でかつ明示的（そしてメンテナンスしやすい）である。
Guiceに、SpringのXML（あるいは新しいJavaベースのコンフィギュレーション）との類似性を見出そうとする評論家もいる。
Most times, there isn't any, but sometimes you can't use annotations, and you need to manually wire up an object (a 3rd party component for example). When this comes up, you write a custom provider. A custom provider adds one level of indirection to your configuration and is roughly 1:1 with Spring's XML in complexity. The remaining majority of the time, you'll write significantly less code.
Eric Burke recently ported a Spring application to Guice:
- At the end of the day, I compared my (Guice) modules — written in Java — to my Spring XML files. The modules are significantly smaller and easier to read. Then I realized about 3/4 of the code in my modules was unnecessary, so I stripped it out. They were reduced to just a few lines of code each.
Oftentimes, it doesn't make sense to port perfectly working code which you won't be changing any time soon to Guice, so Guice works with Spring when possible. You can bind your existing Spring beans. Guice supports AOP Alliance method interceptors which means you can use Spring's popular transaction interceptor.
From our experience, most AOP frameworks are too powerful for most uses and don't carry their own conceptual weight. Guice builds method interception in at the core instead of as an afterthought. This hides the mechanics of AOP from the user and lowers the learning curve. Using one object instead of a separate proxy reduces memory waste and more importantly reduces the chances of invoking a method without interceptors. Under the covers, Guice uses a separate handler for each method minimizing performance overhead. If you intercept just one method in a class, the other methods will not incur overhead.