ruby - Ruby 依存性注入ライブラリ

Question

私はいくつかの Ruby 依存性注入ライブラリを見てきました。特に、 NeedleとCoplandをチェックしました 。それらはかなり前から存在していますが、あまり使用されていません。

これら 2 つのライブラリを使用することの長所と短所は何ですか? Merb / Datamapper's Hookなど、多くのライブラリ / フレームワークがこれら 2 つのライブラリをうまく利用できるようです。

Answer 1

Copland と Needle を書いた Jamis Buck は、Needle、依存性注入、および Ruby の世界でのそれらの有用性についてここに投稿しました。

長いですが、読む価値はありますが、質問に最も関連する単一の段落が必要な場合は、最後の直前から次の段落をお勧めします。

DI フレームワークは不要です。より厳格な環境では、それらは価値があります。Ruby のようなアジャイル環境では、それほどでもありません。パターン自体はまだ適用できるかもしれませんが、すべてに特別なツールが必要だと考える罠に陥らないように注意してください。Ruby は Play-Doh です。そのままにしておきましょう。

HTH

Answer 2

http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/：これは、JamesBuckの記事よりもはるかに意見の少ない別の記事です。結論として、依存性注入は必要ありません。これは、rubyが同様に機能し、Javaの世界には実際には存在しない優れた代替手段を数多く提供しているためです。

それらの選択肢の1つはミックスインです。これはJavaにはないものであり、もう1つは、言語内のほぼすべてのものをオーバーライド/再定義する機能です。その他の機能には、基本的に任意のメッセージを任意のオブジェクトに送信できる動的型付けが含まれ、そのメッセージの実装が提供された場合でも、問題なく機能します。これらすべてが連携して、DIフレームワークの必要性の多くを取り除きます。そのようなデザインパターンはRubyでも有効であり、それを使用することが理にかなっている場合もあります。

上記のAlexeyPetrushinが指摘するDIに関するもう1つのポイントは、依存性注入は主にデザインパターンであり、ツールは二次的なものであり、主にJavaの特定のものの面倒な作業を取り除くことです。ルビーでは、Javaで春やguiceが行うことのほとんどを簡単にエミュレートできます。したがって、本格的な依存性注入フレームワークは、Rubyでは本質的に冗長です。

そうは言っても、DIフレームワークを持つことは、最終的には配線の面倒な作業の一部を取り除くことができるので、ちょっといいこともあります。Ruby固有のDIフレームワークを保証することはできませんが、playdohの性質により、物事の維持/拡張が困難になるため、最終的に別の言語（Javaでも）で書き直されたRubyプロジェクトをたくさん知っています。これは、さまざまな強力な言語機能を使って開発者が足を踏み入れていることに大きく関係していると思います。DIフレームワークを持つことは、これを防ぐのに役立つかもしれない少しの構造とイディオムを課します。

Answer 3

ここにもう1つのIoCがありますhttp://alexeypetrushin.github.com/micon

私はこれを Web フレームワーク (Rails ではない) のコア コンポーネントとして使用しました。ここで動作していることがわかります - http://ruby-lang.info (このサイトはそれを利用しています)。また、多くの時間とコードを節約できたので、個人的には (状況によっては) IoC が非常に便利だと思います。

DI フレームワークは不要です。より厳格な環境では、それらは価値があります。Ruby のようなアジャイル環境では、それほどでもありません。パターン自体はまだ適用できるかもしれませんが、すべてに特別なツールが必要だと考える罠に陥らないように注意してください。Ruby は Play-Doh です。そのままにしておきましょう。

Jamis Buck の話を見ましたが、彼の意見には賛成も反対もありません。その理由は次のとおりです。