アスペクト指向プログラミングを実装していると、混乱します。なぜDojoは2つの異なるアスペクトライブラリファイルを使用する必要があるのでしょうか。
いつ使用するか
dojo.aspect and dojox.lang.aspect ?
アスペクト指向プログラミングを実装していると、混乱します。なぜDojoは2つの異なるアスペクトライブラリファイルを使用する必要があるのでしょうか。
いつ使用するか
dojo.aspect and dojox.lang.aspect ?
私はこれまで聞いたことがありませんが、2008年までの最新のコミット日にdojox.lang.aspect
よると。git log
dojox.lang.aspect
著者のEugeneLazutkinによる記事になぜ存在するのかについての説明を見つけることができます: Dojoを使用したJavaScriptのAOPアスペクト。
場合によってはあまり意味がありませんが、の主な役割は
dojo.connect()
DOMイベントを処理することであることを理解する必要があります。[...]
要約すると、イベント!=AOPです。イベントはAOPのすべての側面をシミュレートすることはできず、イベントの代わりにAOPを使用することはできません。
したがって、JavaScriptのAOPは単純に聞こえます!まあ、実際にはいくつかの厄介な場所があります:
- すべてのアドバイスを関数として実装するにはコストがかかります。
- 通常、反復は再帰呼び出しよりも効率的です。
- コールスタックのサイズには制限があります。
- 呼び出しを連鎖させた場合、それらを再配置することは不可能になります。したがって、途中で1つのアドバイスを削除したい場合は、運が悪いことになります。
- 「アラウンド」アドバイスは、実行の順序を変更する以前に添付されたすべての「前」および「後」のアドバイスを「食べ」ます。「前」のアドバイスがすべての「周り」のアドバイスの前に実行されることなど、これ以上保証することはできません。
- 通常、「アラウンド」アドバイスを元の関数から切り離すために、proceed()関数が使用されます。それを呼び出すと、アドバイスメソッドまたは元のメソッドのネクストインチェーンが呼び出されます。
- 私たちの側面はオブジェクトですが、静的オブジェクトにしたい場合もあれば、操作対象のオブジェクトの状態を考慮して作成された動的オブジェクトにしたい場合もあります。
これらおよびその他のいくつかの問題は、dojox.lang.aspectで解決されました(現在トランク内にあり、Dojo 1.2でリリースされる予定です)。
最新のDojo1.7の時点では、イベントとアスペクト、つまりとの間dojo/on
を区別する傾向が強くなっていますdojo/aspect
(どちらも以前に実装されていましdojo.connect
た)。
使用法の観点から、dojo/aspectはdojox/lang/aspectの非常に単純化されたバージョンです。
dojo / aspectを使用すると、名前付き関数(たとえば、「xhr」クラスの「get」メソッド)に対応するアスペクトを作成でき、xhr.getが呼び出されたときにいつでもアドバイスの前、後、または前後を作成できます。
一方、(TMHO)dojox / lang / aspectのみが、aopで遊ぶのに十分な機能を提供します。これにより、正規表現を使用してポイントカットを定義できるため、「名前がget onanyobjectで始まる関数に対してアラウンドアドバイスを実行する」などのことが可能になります。
アスペクトが適用される関数名または正規表現の配列を渡すこともできます。
phusickが指摘したブログ投稿はその良い例を示しています。