多くの人が、GoF 設計パターンの大部分は、ファースト クラス関数が存在しないための回避策にすぎないと主張しています。Java がラムダ式を取得しようとしている今、これらのパターンのどれがそれらの影響を受けるでしょうか? 劇的に単純化または一般化できるものはどれですか? そして、どれが基本的に同じままですか? 実用的な例は大歓迎です。
2 に答える
行動パターンの変化を最も多く見られると思います。
テンプレート メソッド- テンプレート メソッドはますますほとんど使用されなくなり、代わりに、オブジェクトが AbstractTemplate をサブクラス化する代わりに、AbstractTemplate に関数を渡すようになります。私はこれについてかなり前にブログを書きました: http://hamletdarcy.blogspot.ch/2007/11/groovy-closures-end-of-template-method.html
オブザーバー パターン- 新しいイベントで更新されるオブザーバーのリストを保持する必要がなくなるため、オブザーバーが簡素化されますが、代わりに、新しいイベントでコールバックする必要がある関数のリストを保持します。したがって、Observer インターフェイスはなく、関数オブジェクトだけです。
状態/戦略パターン- これらは構造的に同等であり、意図が異なるだけであるため、これらをグループ化します。ストラテジーの使用は、実装が容易であるため、より一般的になります。親戦略と戦略サブクラスは必要ありません。必要なのは関数だけです。そのため、関数をパラメーターとして渡すだけで、実際には戦略パターンを使用するのは簡単です。
全体として、1 つのメソッドのインターフェイスを必要とするパターンは実装が容易になると思います。これにより、2 つの効果が得られます。1) これらの関数型パターンをもっと使用し、2) それらをパターンとして参照するのをやめますが、単に「関数を渡す」だけです。
自分のやりたいようにやればいいのですが、「JavaScript の良い部分」は、言語で関数を活用するための非常に優れた入門書だと思います。手に取って読んでもいいですね!
私はこの質問に答えるために、いくつかの GoF パターンとそれに対応する機能を実際のコード例で分析した一連の記事を書いています。特に、コマンドと戦略、テンプレートとオブザーバー、デコレーターと責任の連鎖、インタープリターとビジターを再検討しました。