Javascriptが今後数年間でWebのユビキタスプログラミング言語であるように見えて、新しいフレームワークが5分ごとにポップアップし、イベント駆動型プログラミングがサーバー側とクライアント側の両方をリードしています。
Javascript開発者は、従来のデザインパターンを他の言語や環境よりも重要であると考えていますか?.
Javascript開発者が定期的に使用している上位3つの設計パターンに名前を付け、それらがJavascript開発にどのように役立ったかの例を挙げてください。
Javascript開発者は、従来のデザインパターンを他の言語や環境よりも重要であると考えていますか?.
従来のデザインパターンはJavaScriptには適用されません。
適用されるのは、モジュール式で機能的なコードの記述です。
コンストラクタとファーストクラス関数を組み合わせて使用する必要があります。
私はJavaScript開発者として、JavaScriptをJavaではなくLISPとして扱うことを個人的に推進しています。したがって、古典的なOOPコードをエミュレートするのではなく、モナドと高レベルの関数型コードをエミュレートするようにしてください。
Javascript開発者が定期的に使用している上位3つの設計パターンに名前を付け、それらがJavascript開発にどのように役立ったかの例を挙げてください。
繰り返しになりますが、デザインパターンはそれほど適用されませんが、以下の3つの重要な構成要素があります。
new
ありまたはなしのObjectファクトリの使用従来のデザインパターンを使用して同じ種類のコードを実行する場合と比較して、これらの種類のテクニックの例を示すことができるある種のコンテキストを残してください。
古典的なDesign Patternsのいくつかと、それらをjsに実装する方法、およびjs自体により適した代替パターンを見てみましょう。
オブザーバーパターン:
_node.js
_では、これは単に_events.EventEmitter
_です。 jQuery
では、これは_$.fn.bind
_ && _$.fn.trigger
_です。 backbone
では、これは_Backbone.Events.trigger
_および_Backbone.Events.bind
_です。これは、日常のコードで使用される非常に一般的なパターンです。
「ここでオブザーバーパターンを使用しています!」いいえ、これは単にメッセージをやり取りするための低レベルの方法、または変更をカスケードする方法です。
たとえば、バックボーンでは、すべてのMVCビューがモデルのonchange
イベントにバインドされるため、モデルを変更すると、変更がビューに自動的にカスケードされます。はい、これは強力なパターンですが、イベント駆動型プログラミングでは、どこでも使用されていることに気付かなかったため、よく使用されています。
WebSocket
プロトコルには、_.on
_イベントにバインドするために使用する_on("message", ...
_があります。繰り返しますが、これは非常に一般的ですが、従来のOOP based while (byte b = Stream.ReadNextByte())
ではなく、ストリームのオブザーバーです。
これらはすべて、Observerパターンの強力な使用法です。しかし、これはあなたが使うパターンではありません。これは言語の単純な部分です。これは単なるコードです。
Mementoパターン:
これは単なるJSONです。オブジェクトの状態をシリアル化して、アクションを元に戻すことができます。
_function SomeObject() {
var internalState;
this.toJSON = function() {
return internalState;
}
this.set = function(data) {
internalState = data;
}
this.restore = function(json) {
internalState = JSON.parse(json);
}
}
var o = new SomeObject();
o.set("foo"); // foo
var memento = JSON.stringify(o);
o.set("bar"); // bar
o.restore(memento);
_
JavaScriptでは、ネイティブにmementosのAPIをサポートしています。任意のオブジェクトにtoJSON
というメソッドを定義するだけです。 _JSON.stringify
_を呼び出すと、オブジェクトで_.toJSON
_が内部的に呼び出され、JSONにシリアル化する実際のデータが取得されます。
これにより、コードのスナップショットを簡単に作成できます。
繰り返しますが、これは記念品のパターンではありません。これは、JSONであるシリアル化ツールを使用するだけです。
状態パターン/戦略パターン:
状態パターンは必要ありません。あなたはファーストクラスの関数と動的な型を持っています。関数を挿入するか、その場でプロパティを変更します。
この回答を主観的な意見としてください。
JavaScript開発者は、従来のデザインパターンを他の言語や環境よりも重要であると考えていますか?
Gang of Four のような従来のデザインパターンを意味する場合、ほとんどの手法は、「実装ではなくインターフェイスへのプログラム」や「クラス継承よりも好意的なオブジェクト構成」のように、言語やプラットフォームにとらわれず、 JavaScript開発者にとっても同様に重要です。
言語の機能は使用に大きな影響を与える可能性があるため、創造的、構造的、行動的などのより具体的なパターンを他の言語と同じように、または他の言語と同じくらい頻繁に使用する必要はありません。したがって、一部の言語(JavaScriptを含む)は、それらが提供する機能または構文糖度に基づいて独自のデザインパターンを持っています。
一般に、従来のデザインパターンは他の言語と同様に重要ですが、JavaScript固有のパターンは従来のものよりも重要です。
javaScript開発者が定期的に使用する上位3つの設計パターンに名前を付け、それらがJavascript開発にどのように役立ったかの例を示します
Essential JavaScript Design Patterns の中で、私は主にこれらを使用します:
1。コンストラクタパターン(プロトタイプあり)
特にnode.jsのものを書くときのサーバー側では、ネイティブのカプセル化が欠けていますが、モジュールを書くのに適しています。また、GitHubでリポジトリを参照する場合、他の多くの開発者に人気があるため、このパターンに精通すると、他のコードをよりよく理解するのに役立ちます。
2。モジュールパターンを明らかにする
カプセル化によるモジュール性を提供します。
3。 DRYパターン
これはむしろシナリオ固有ですが、すべての開発者は可能な限り(不可能)に使用する必要があります。
デザインパターンは、CSのデザインクラスで教えられます。それらは必須ではありませんが、考え抜かれた解決策を得るために類似の状況を見つけることができれば本当に役立ちます。
また、プログラマーがより簡単に通信できるようになります。パターンについても同僚と話すことができます。ここに私のオブザーバーがいると言うと、何が起こっているのかよく理解されています。
人々は自然に自分でデザインパターンに適合するソリューションを考え出しますが、デザインパターンは、役立つ用語や標準的なアイデアを定義するのに役立ちます。
パターンについて特筆すべきことは何もありません。最もすばらしいのは、繰り返し使用できる方法で標準化および定義されたアイデアであることです。
Javascript開発者として、あなたは伝統的なデザインパターンを重要か、それともそれほど重要ではないと考えていますか?
彼らは不可欠です。
これは、再利用可能なソリューションの概念が言語を超える可能性があるためです。 -構文の変更-実装の変更-パターンの概念はまだ存在します。
あらゆる言語の開発者は、構文ではなくパターンを学習することにより、高度なJSを学ぶことができます。これを知らない人は逃しています。
Javascript開発者が定期的に使用しているため、上位3つの設計パターンに名前を付けてください
頻繁に使用されるパターンがいくつかあります。ただし、高度なJSでは非常に一般的で強力であるため、知っておくと役に立ちます。
1-名前空間-コードをオブジェクトでラップします。
var x =(function(){})();
2- ObjectConfiguration、工場のようなパターン。 -オブジェクトを変数の束ではなく関数に渡します。
var product = factory({});
3-コールバック関数。 -関数がパラメーターとして渡され、タスクが完了したときに呼び出されます。
function longTask(function(){//完了したら電話してください});
私が言ったように、これらはパターンではないと主張する人もいるかもしれませんが、それらは非常に一般的で非常に強力であり、一般的な問題に対して実際に非常に有用な再利用可能な解決策であるため、言及する必要があります。それがデザインパターンの定義です。
すばらしい質問です。
お役に立てば幸いです。