inversion-of-control - SmalltalkとIoC

Question

.NetとJava用のIoCフレームワークがたくさんあります。Smalltalkに同等のフレームワークがない理由を誰かが知っていますか？これは何よりも哲学の質問です。Smalltalkのやり方で、IoCフレームワークの必要性を排除する何かがあるのではないかと思います。

Answer 1

関数はsmalltalkの第一級市民であるため、フレームワークなしでIoCを使用するのは簡単です。

Answer 2

MVCは Smalltalk で発明されたものであり、おそらく元のInversion of Controlフレームワークです。Java の対応するものよりもいくらか軽量ですが、データを保持するモデルの基本概念、コントローラーから伝搬されたイベントに応答してデータをレンダリングするビューがあります。

冗談ではありませんが、Java では、大量のボイラープレート コードを使用せずに Web アプリケーションを実行するために、実際には多くのフレームワーク サポートが必要です。Smalltalk は、continuationsなどのプログラミング イディオムをサポートしています。これにより、作成者は実際にはイベント駆動型のコードを書いていないふりをすることができます。 Seasideはこのように動作し、より柔軟な開発パラダイムで IoC の利点を提供します。

編集: MVC は Smalltalk の UI のフレームワークです (おそらくそれ自体はフレームワークではありませんが、クラス ライブラリにはそのサポートが組み込まれています)。ビューとモデルがコントローラーによってディスパッチされたイベントに応答するという点で、コントロール プロパティの反転があります。Inversion of Control は、フレームワーク内の設計パターンであり、Java アプリケーションで大規模なボイラープレートの必要性を減らすために使用されます。アプリケーション フレームワークの一部の定義では、制御の反転は、フレームワークとライブラリを区別するものと見なされる主要なプロパティです。

Answer 3

IOC または Dependency Injection パターンは、Smalltalk 環境には実際には存在しない問題を解決すると思います。Smalltalk は型指定されていない動的言語であり、メッセージ パッシングを使用して通信します。これにより、言語レベルで本質的に疎結合されたオブジェクトが作成されます。どのオブジェクトも、メッセージを処理できる限り、タイプに関係なく別のオブジェクトにメッセージを送信できます。したがって、いつでも依存関係を変更することは比較的簡単で自然なことだと思います。依存関係をいつ、どこで、どのように変更するかを決定する必要があります。

Answer 4

これにはいくつかの理由が考えられます。1つは、本質的に冗長な「IoC」修飾子をわざわざ使用していないことです。フレームワークを呼び出すと、制御フローの反転が意味されるためです。

もう1つは、Smalltalk言語が、クロージャの形で「IoC」フローを直接サポートすることです。クロージャを使用したプログラミングの結果の1つは、フレームワークに見られる制御の流れが、「通常の」流れの感覚から「反転」した感覚を呼び起こすほど大きく異なるようには見えないことです。むしろ、クロージャを使用すると、制御の流れは、常に、そしてどこでも、これら2つの視点の間を行き来します。単一のステートメント内でも。

3番目の理由は、おそらく、クロージャーがなくても、説明されている「制御の反転」がフレームワークに一意に関連付けられていないことです。同じフローが、I/Oを含むほとんどの形式のコードに見られます。

第4に、Smalltalkersは、構造の概念やメンバー関数の呼び出しよりも、オブジェクトの概念とオブジェクト間で送信されるメッセージに大きく依存しているため、おそらく他のフローよりもこの種のフローを使用します。クロージャがない場合、これら2つのビューは同等であり、互換性がありますが、クロージャを追加すると結果が変わります。使用中の制御フローの感覚は効果の1つです。

最後に、REPLスタイルの制御フローを「より単純な」ものとして説明することも考えられますが、「通常の」フローの「逆」の意味であり、他のほとんどすべての場所で使用されているという意味で通常です。

要約すると、Smalltalkにも同じ種類のフレームワークが存在します。私たちはそれらを少し異なって説明します。違いは、少なくとも部分的には、他の多くの環境ではまだ提供されていないSmalltalkのクロージャの存在と利用によるものです。特に、C ++、C＃、およびJavaです。

Answer 5

Javaでは、次のようなものを書くと依存関係が作成されます

MyClass32 temp = this.theThing();

これで、コードは MyClass32 クラスに依存します。あなたのコードはそれなしでは機能しません。そのクラスに変更を加えると、コードがコンパイルできなくなり、コードに多くの追加の変更が必要になる可能性があります。これにより、クラスに依存するクラスにさらにコードの変更が必要になる場合があります。余分な作業がたくさん。

Smalltalk では、temp := self theThing; と書きます。

#getTheThing によって何が返されても、コードは機能します。あなたのコードはクラス MyClass32 に依存していません。唯一の依存関係は、「temp」が送信するメッセージを理解する必要があることです。

したがって、ある意味では、依存性注入フレームワークの目的は、Java のような静的に型付けされた言語を動的に型付けされた言語のように機能させることです。

そうは言っても、私が Smalltalk でよく従う設計パターンがあります。SOME クラスを返す MyClass のようなクラス メソッドを作成します。名前が「MyCLass」である必要はありません。それはいくつかのクラスの 1 つであり、夜に別のクラスを返す可能性があります。このパターンは Smalltalk MVC に存在し、View クラスにはメソッド #defaultControllerClass があり、通常はサブクラスによって再定義されます。