前回の号では、キュー管理コンポーネントの設計について説明し、それに「スマート キュー」という派手でユニークな名前を付けました。今回は、前回の設計結果を実践し、コードで実装します。
まず、ソース ファイルのレイアウトを検討する必要があります。つまり、コードを独立したファイルに分割する方法を決定します。なぜこれを行うのでしょうか?前回の号の最後で、このコンポーネントは「外部コード」を使用すると述べたのを覚えていますか?コードの目的を区別するために、コードを少なくとも 2 つの部分 (外部コード ファイルと Smart Queue ファイル) に分割することが決定されました。
区別する目的は 1 つだけで、2 番目に、それらを独立したファイルに分散することがコードの保守に有益です。将来のある日、キュー管理の既存の基本機能にいくつかの新しい拡張機能を追加するか、それを特定のタスクを実装するコンポーネントにパッケージ化することに決めたが、既存の機能 (内部実装) と呼び出しを維持したいと想像してください。メソッド (外部インターフェイス) が変更されない場合は、新しいコードを別のファイルに書き込むことが最良の選択です。
さて、次回はファイルレイアウトの話に焦点を当てますが、ここからが本題です。もちろん、最初のステップは、コンポーネント用の独自の名前空間を作成することです。コンポーネントのすべてのコードは、このトップレベルの名前空間に制限されます。
var SmartQueue = window.SmartQueue || {};
SmartQueue.version = '0.1';
初期化中に名前空間の競合が発生した場合は、それをプルして使用します。通常、この競合はコンポーネント コードへの繰り返しの参照によって発生するため、「プルオーバー」するとオブジェクトが同じ実装で書き換えられます。最悪の場合、ページ上に SmartQueue と呼ばれる別のオブジェクトが存在する場合、それは恥ずかしいことです。実装をオーバーライドします。これ以上名前の競合がなければ、基本的に 2 つのコンポーネントは問題なく実行できます。バージョン番号も付けます。
次に、3 つの優先順位に従って SmartQueue 用の 3 つのキューを作成します。
var Q = SmartQueue.Queue = [[], [], []];
まだタスクが追加されていないため、それぞれは空の配列です。ちなみに、後で配列にアクセスしたい場合は、Q[n] と書くだけです。
次に、主人公のタスクが堂々と登場します。新しいタスクの作成方法はここで定義されています。
内部の具体的な詳細については説明しませんが、必要なコメントがあれば、一般的にコードは自己記述的になります。これは後続のコードにも当てはまります。ここで顧客 (ユーザー) に伝えます。新しい SmartQueue.Task インスタンスを作成する場合は、少なくとも 1 つのパラメーターをこのコンストラクターに渡す必要があります (最後の 3 つはデフォルトの処理では省略できます)。そうしないと例外がスローされます。
しかし、これでは十分ではない場合があります。顧客は、既存のタスクから新しいインスタンスをクローンしたり、「無効なボディ」(一部のタスク属性を持つオブジェクト) から「正常なボディ」(実際のタスク オブジェクト インスタンス)を修復したりする必要があります。上記の構築方法は少し不快です。顧客は次のように記述する必要があります。
var task1 = new SmartQueue.Task(obj.fn, 1, '', obj.dependency);
出典: Alipay UED
var T = SmartQueue.Task = function(fn、レベル、名前、依存関係) {
if(fn のタイプ !== FUNCTION) {
throw new Error('無効な引数の型: fn.');
}
this.fn = fn;
this.level = _validateLevel(レベル) レベル: LEVEL_NORMAL;
// 名前の種類を検出します
this.name = 名前の種類 === STRING && 名前名 : 't' + _id++;
// 依存関係は「オブジェクト」として取得できるため、代わりにinstanceofを使用してください。
this.dependency = 依存関係 配列の依存関係 : [];
};