約束は宝石アートです

この記事は、ジュエリーの人気が高まっているために仕事を辞め、以前の仕事に少し手を加えなければならなかった宝石商のために書かれています。



プログラミングの新しい概念に出くわすたびに、それが現実の世界に反映されていることを見つけようとします。約束-それらは合意であり、それは何ですか？ 誰かが将来誰かのために何かをするプロセスの説明として、約束を追い越す自由を取ります。 次に、この説明を広義に形式化しようとします。 私たちの抽象的な想像力では、3つのオブジェクトのセットを一度に表示できます。1つ目は約束するもの、2つ目は約束するもの、3つ目は約束するものです。 すでに複雑な3セットのオブジェクト、それらはどのような関係に作用しますか？、どのように接続されますか？ いくつかの質問。 単純化のために最初にできることは、最初のセットと3番目のセットを組み合わせることです。それらの性質は同じであるため、人、コンピューティングノードなどになる可能性があります....検討中の特定の技術環境のフレームワーク内で、Node Js bundles、Q libraryユナイテッドセットはそれ自体をロックします。 実際、私たちのケースでは、コード内で何かが実行されたと言ったときに自分自身に約束をします。 実際には、一度に2セットの場所が存在する可能性があるタスクが存在します。 たとえば、共同計算を行う相互作用するソフトウェアノードから環境を想像することは簡単であり、2つのセットはまったくありません。 しかし、例としてQライブラリを使用してNode.Jsのpromiseを見ていきます。



したがって、できることは、いくつかのタスクセットを完了することを約束することだけです。 さて、多くのオブジェクトがあるとすぐに、私たちのケースでは多くの問題があるので、数学者が行うように、このセットにすぐに関係を導入できます。 そして、関係の1つがすぐに表示されます。これは、私たちの場合に適した方法です。順序の関係です。 そしてすぐにわかるように、この関係はpromiseオブジェクトの「then」メソッドによって実現されます。



現実の世界に戻って、プログラムマネージャーに次のような約束をすることは可能ですか？

「サーシャ、よく聞いてください、初期化モジュールを作成した後、ブートモジュールを作成しますか？」

サーシャはそのような約束に満足せず、空中にぶら下がっている関係の連鎖ではなく、何かに基づいて構築する必要があることは明らかです。 次に、約束を見てみましょう。自分のために特定の未来を自動的に構築すると約束したとき、行動を具体的な未来に投影し、天才はそれを永遠に投影します、計算の概念も変化しているという理由だけで、近い将来を考慮します。 そして、ここで新しい疑問が生じますが、Node Jsの特定の未来をどのように想像しますか。



Node.jsは、非ブロッキングI / Oを使用したイベント指向および非同期（またはリアクティブ）プログラミングに基づいています-これはWikiから取得したものです。 約束の点で、これが私たちにとって何を意味するのか。 「ティック」コントロールがスクリプトに転送されるたびに矢印が付いた時計を想像してください。「いいね」コントロールがノードに転送されると、ノードが「so」フェーズでのみ動作することを意味しません。そのため、「私たちは、彼によって割り当てられた非同期I / Oタスクの問題に関する彼の活動の結果を彼が私たちに通知すると仮定します。 未来を構築するための最初の試みを行い、それを再びティック間に分割しました。また、多くのティックの順序関係を再度紹介します。 どうやらそこから抜け出す方法はないようです。そして、因果関係なくして人々がどのようにプログラムするのかわからないことに感謝します。 Tick-to-Tackモデルに目を向けると、将来のモデルを単純化し、約束をより実現することにより、責任範囲を狭めます。

今、私たちは将来、常に「ティック」フェーズがあることを知っています。私たちはこの未来の主権ホストです。 制御ノードを提供することで、タスクをロードすることが期待され、通常はこれを行います。 これを行う方法、最初から、開始スクリプトがあり、ティックフェーズで実行を開始します。実行の結果は、基本ノードAPIによって形成されるタスク、たとえばfs.readFile(filename, [options], callback)



になりますタスクはありません。プログラムは作業を終了します。 タスクが完了するとすぐに、ノードは次の「ティック」フェーズでコールバックの実行を計画し、それに制御を移します（コールバック）。 そして、その中に他のNodeタスクを設定します。 また、非同期API全体がNodeのコールバックに実装されているため、説明するタスクはそれらにあります。

そして、この状況は「コールバック関数の地獄」と呼ばれています。 ところで、フォーラムで特定の問題を議論するとき、人々はこの地獄と非常に良い友達です。なぜなら、フォーラムでのメッセージ交換のスタイルはこのスタイルのすべての基準を満たしているからです。 そして、なぜこれがコードの問題になる可能性があるのでしょうか、そうです、プログラマーはコードの長さに対してのみ支払われます、水平方向に拡張するために誰も支払わないか、そうでないかもしれません。 もちろん、彼らはコーディングスタイルの観点からコールバック地獄について書いており、そのようなスタイルの背後に隠れているかもしれないものをわずかに省略しています。



この状況を見てみましょう。

 a(arg1, function() { var x1; b(arg2, function() { var x2; setInterval(function Task() { console.log('tik'); }, interval); }); })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、何かを行う間隔間隔でNodeタスクを間隔で設定すると、呼び出しツリーのブランチ全体はチェーン、クロージャーとも呼ばれ、タスクが存続して実行されている限りメモリ内に存在し続けますが、使用されない場合があります上で説明した変数と引数x1、x2、arg1、arg2 ...そして、これは、そのようなネストされたタスクを書く価値があるかどうか、すでに疑問に思っています。 たとえば、このケースでは、タスクは単に「tick」という単語を表示する場合があります。



しかし、これらはjavascriptの問題であり、その性質は、すべてが実行、解釈の段階で発生する超動的言語であるため、もちろんコードの構造は実行のセマンティクスを反映しています。 静的なコンパイル言語では、関数変数と引数はスタックまたはレジスターに配置され、関数が作業を終了するとすぐに解放され、そのような問題は発生しません。 そして、無駄なメモリ消費やパフォーマンスの低下につながる可能性がある状況がある場合は、それらを回避する方が良いのですが、どのように？



そして、ここに約束の概念があり、それに続いて、たとえば上記のような状況を回避することができます。 もう少し上に、私たちは未来の概要を説明し始め、それを2つのフェーズに分割し、そのフェーズでティックを描画するか、Node jsをレンダリングするタスクを提供できることに気付きました。 しかし、コードを連続して2回続けて記述するとどうなりますか。上記のコードを参照してください。 確かに、特定の間隔でタスクは2回実行されますが、どのような順序で実行されますか？ しかし、誰もこれを明確に教えてくれません。特定の順序を期待することしかできませんが、保証されているわけではありません。 今、私たちはさまざまなタスクの順序関係を想像力に導入し、その履行を要求するすべての権利と約束の概念を持っていることを思い出します。そして、そのような権利を与えると、タスクをチェーンにリンクし、実行することを要求できますひとつずつ。 しかし、それでは例を挙げないで、少し違うことから始めましょう。 そして、javascriptでの実装の観点からの約束は何でしょうか。 また、javascriptの一部として表示するオブジェクト（タスク）の数。 たくさんのタスクについて、「私たちが約束するもののような」多くのオブジェクトについて私が暗黙のうちに話し始めてから、それを多くの約束に変えたことに気づかなかった。 このセットのオブジェクトにいくつかの二重性が見られます。 そのため、ここでは徐々に特定の実装に移行しています。

プログラミング言語のフレームワーク内で問題のセットの順序関係を実現するためには、このセットの各要素に二重の性質を与えなければなりません。これは約束でもありタスクでもあります。 つまり ここで、タスクは実行のための命令のセットであり、実行されるタイミングはわかりません。約束は正確に順序関係自体の原因であり、タスクの実行が開始される瞬間を決定するメカニズムは隠されています。 約束は、タスクを遂行するための条件が規定されている紙の契約などの具体的なものであり、タスクはプロセスであり、無形の何かであり、その二重性は一対の空間（約束）-時間（タスク）と比較できます。 スペースをメモリに関連付け、時間をコード、指示に関連付けることができます。 ただし、javascriptにはこの二重性がネイティブに含まれており、関数はオブジェクトメソッドだけでなくプロパティも持つことができます。 欲しいものを選択してください。



Qライブラリの開発者は、最適なオプションはネイティブjavascript関数をタスクに割り当て、オブジェクトをpromiseに割り当てることであると判断しました。 タスクをエンコードする単純な関数を、ある概念のフレームワーク内のタスクにするにはどうすればよいのでしょうか？それをすべてと区別するために、どうすればよいでしょうか？ Qがタスクから通常の機能を分離できる一方で、この機能が存在しない場合にpromiseテクノロジーを適用できるように、彼女には何らかの分類機能が必要であることは明らかです。 Javascriptには十分な分類オプションがあります。 しかし、開発者は関数ラッパーメカニズムを使用することにしました。これは、機能的javascriptの性質に非常に自然に美しく適合します。 つまり ライブラリユーザーに伝え、関数を記述し、特別なラッパーライブラリ関数に渡します。コンテキストではそれらをタスクと見なします。 つまり 実際、私たちは一般に、約束の概念で作業を開始するために特別なことは何もできません。

つまり、2つのタスクの順序関係を保証するために、次のように記述できます。

 Q.fcall(function task1() {…}).then(function task2(){…});
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、fcall、次にラッパー関数のみがタスク1とタスク2を取得し、タスクになります。関数に対しては何もしません。これらの関数は、上記のコードを実行する過程で隠しプロパティを蓄積しません。 このコードから得られるものですが、task1のtask2の実行が保証されますが、すでに次の「ティック」に含まれています。 タスクの実行とは、関数の実行、つまり 関数内でreturn式またはその最後に到達したとき（yieldステートメント、ここでは見逃します）。 関数task1およびtask2に非同期コールバックを使用したAPI呼び出しがある場合、実行シーケンスはコードによって保証されません。上記を参照してください。これに対して特別なアクションを実行しない場合、コールバックは単独で実行されます。 次に、そのような構造が必要な理由を尋ねると、単に書くことができます：

 task1(); task2();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、可能ですが、たとえば、最初の1つが内部で非同期APIにアクセスし、2つ目がそうでない場合、task1（）コードで順序を設定します。 task2（）; 内部で何もせずに失敗します。 別の例では、タスクA（）、B（）、C（）のようなシーケンスがあります。AとCは非同期で、Bは同期ですQ.fcall(A).then(B).then(C)



、および関数Bで後述するように、特別なpromiseオブジェクトを返す必要はありません。Qライブラリがこれを行います。



私たちは今、約束に目を向けます、そして、彼らがここに現れる場所、これらの紙片は、紙片なしで言うように、私の兄弟と私は双子ではありません。 建設の腸では、上記を参照して、約束が生まれ、その実装の結果が約束になります。 内部でこれがどのように行われ、Qライブラリが実装されるとしばらく放置されますが、最も重要なことは、Q関数のモナド（fcall、thenなど）と呼ばれることがある一連の呼び出しがほとんど常に約束を生成することを理解することです他のモナド間のリンクとして。 作成されたものの腸には状況を完全に制御するのに必ずしも十分ではないという説明、そしてもちろん、ライブラリは約束を明示的に作成するためのメカニズムを提供します。



それなしで行うことは可能ですか？なぜそれが必要ですか？ 同期タスクのみを使用する場合、明確な約束を作成する必要はありません。 非同期ノードJS APIを使用する場合、Qライブラリーには、Promiseを暗黙的に作成するラッピング関数があります。 非同期タスクで作業する場合でも、明示的にプロミスを作成するためのメカニズムを使用しない理論的な可能性があります。 さらに、このラッパースタイルは、非同期関数の最後のパラメーターとしてフォーム（エラー、結果）のコールバック関数を備えた他のライブラリのすべての非同期関数に適用されます。



マニュアルライブラリQの例を次に示します。

 Q.nfapply(FS.readFile, ["foo.txt", "utf-8"]).done(function task (text) { … });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、標準のreadFile Node JS関数の呼び出しがどのように呼び出されるかを確認できます。 nfapply呼び出しになります。これは、ラップされた関数と、次のティックで呼び出されたときにreadFileに渡される引数の配列の2つの引数を取ります。 そして、コールバック関数readFileはどこに行きましたか？ このような構造では、関数が自動的にその場所をとります;この例では、名前はtaskであり、promise doneオブジェクトメソッドに渡されます。 驚いたことに、Qは非同期関数がタスクを完了するとすぐに制御をタスクに移すことに気付き始めました。 そして、彼女がそれをどうするか



nfapply関数がほぼ行うことの擬似コードは次のとおりです。

 function nfapply(readFile, [args…]) { var deffered = Q.defer(); readFile([args…], deffered .resolver()); return deferred.promise; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、遅延オブジェクトが作成されます;そのリゾルバーメソッドは関数を返し、readFile関数のコールバックとして置き換えられるハンドラーを呼び出しましょう。ハンドラーの簡略化された形式は次のようになります。

 function handler(err, result) { if (err) deffered.reject(err); else deffered.resolve(result); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基本的な理解を複雑にしないために、例外処理に関連する問題については意図的に触れません。

非同期関数のラッパーがコールバック関数の外観に制限を課す理由が明らかになりました。ラッパー関数のセマンティクスが劇的に変化し、約束を完全に解決および拒否するプロセスを制御するためにオブジェクトを明示的に作成せずに行うことができないため、引数を交換して場所を変えるだけで十分です。

Promiseオブジェクトを含む遅延オブジェクトを返すQ.defer（）メソッドを呼び出すだけで、Promiseを作成できます。これについては既に説明しました。 また、「遅延」オブジェクトのメソッドを使用すると、実際にそれらと同じことを約束で行うことができます。拒否-拒否、実行-解決、進行状況の通知-通知。 ご自由に質問してください。Qライブラリのフレームワーク内で約束を延期できないのはなぜですか。 一時停止メソッドが実装されていない理由。



順次実行されるタスクのチェーン、関数に戻りましょう。 リレーリレー競技のトレッドミルとして想像してみましょう。 タスクは、距離を走って、次のタスクであるフラグを別のランナーに渡すランナーです。 アイデアのチェックボックスはフィニッシュラインに到達する必要があります。 フラグは、別のタスクがそれを置き換えないと決定するまで、またはフィニッシュラインに到達するまで、あるタスクから別のタスクに渡される約束と考えることができます。 置換は簡単な方法で行われ、実行中にランナーがポケットから旗を取り出して、それを見る時間がない次のランナーに渡します。 すべてのランナーがフラグを変更できます。 コード内で置換を行うためには、関数内にいるだけです-タスクは、promiseオブジェクトを返します。 これを行うと、Qライブラリがこれを理解し、次のタスクは、resolveまたはreject deferredを呼び出して約束を拒否または保持した後にのみ実行を開始します。 以下に、簡単な図、基本的なテンプレートを示します。

 Q.fcall(function task1() { var deferred = Q.defer(); asyncOp(function callback(result) { … deferred .resolve(result); };) return deferred.promise; }).then(function task2(result){ console.log(result); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つのリンクの接続方法を理解していれば、マルチリンクチェーンを簡単に組み立てることができます。 しかし、ここには一つのことがありますが、私たちが検討している有望なタスクのセット全体ではありません。実際には、順序関係があります。 一部のタスクでは順序を決定できますが、そうでないタスクもあります。 また、相互に関連する順序を決定しないものは、相互に独立したタスクのグループに結合でき、並行して実行できます。 この場合、Qライブラリには、この動作を実装できる構造があります。 Q.all関数（[...]）は、promiseオブジェクトの配列を引数として取り、すべてのオブジェクトが実行されるか、少なくとも1つが拒否されるとすぐにそれを知らせます。 そして彼女はそれを単純に行い、すべて同じ約束（約束オブジェクト）を私たちに返します。 並列タスクは、チェーン上の装飾と見なすことができます。 これで、標準的なジュエリーを作成できます。



Q.defer（）を書いたときに遅延オブジェクトを取得するとき、なぜpromiseの約束がすぐではないのか、何らかの補助オブジェクトが必要なのか、ある種の双対性があるのか​​、約束を軌道に入れるプロセスをより詳しく考えてみましょう。 ロケットを軌道に投入すると、離陸中に何が失われますか？ ここでも同じことが起こります。 彼は仕事を延期しましたが、今では大胆に歩けるようになりました。 このオブジェクトを作成するときに必要なのは、原則として、次のメソッドのいずれかの呼び出し、reject、resolveです。これは、約束をいくつかの、まだ変更されていない状態に変換します。 これらのメソッドの呼び出しは、ステップがロケットから分離された瞬間と比較できます。ステップが分離された後、ステップが正常に分離された場合、ロケットはすでに別の状態にあり、その後、加速され、そうでない場合、デブリの状態になります。 , resolve, reject, , , , Q. , . , deferred.resolve(value) deferred.reject(value) value .



, , , , , nfapply, fcall , , . — , .. .



, - .