パターンベースのプログラミングとは何ですか？

プログラミングのパターンとアンチパターンに対する強迫観念を誰かが説明できますか？どんなパターンが何を意味するのか全くわからないからです。プログラミングタスクに直面したとき、問題について少し考え、関連すると思われるデータ構造を書き留め、ソリューションのプロトタイプを作成し、いくつかのモジュールを分離して繰り返します。プロセスのどこにも「ああ、ここにFunkyLookyTasticパターンが必要」とは思いません。

パターンは、一般的なタイプの問題を解決するための一般的なアプローチです。それ以上でもそれ以下でもありません。それらを知って理解することで、他の人の経験を活用して、うまく機能することが示されている種類のソリューションに導くことができ、過去に遭遇した落とし穴を避け、他の人に馴染みのある用語を使用してソリューションを議論できますそのパターンを知っています。

もちろん、パターンを明示的に使用せずに細かい解決策を思い付くことができます。また、特定の問題に実際には当てはまらないパターンを適用しようとすることで、同様に悪い解決策を思い付くことができます。あなたが観察する「強迫観念」は、一般的に概念を発見したばかりの人々から来ていると思います。ほとんどの人は、彼らが何であるかをすぐに認識します。魔法の弾丸ではなく、便利なツールです。

一方、アンチパターンは、コード品質を低下させる傾向がある一般的に観察される動作です。繰り返しますが、これらのいくつかを知って理解することは、そのような振る舞いを避け、他の人でそれを観察するときに（合理的な引数で）修正しようとするのに役立ちます。パターンの乱用をアンチパターンとして説明する人もいます。

パターンは、クックブックに記載されているプログラマーの知識であり、プログラマーがコミュニケーションするための便利な方法でもあります。

他の答えが示唆するように、パターンは本当に一般的な問題に対する一般的な解決策です。利点は、多くの場合、既存のパターンを使用することでより良いソリューションを取得できること、またはコーディングを開始する前にありそうな落とし穴を発見できることです。

他の利点は、コードについて誰かと話しているときです。パターンは、長い説明をいくつかの単語に凝縮する別の種類の専門用語です。パターンを参照せずに、「工場からオブザーバーが追加された」と説明してください。できますが、時間がかかります。

ほとんどの開発者は、新しいパラダイムや方法論に夢中になります。最初にデザインパターンについて聞いたとき、そうしました。デザインパターンは、その名前が示すとおりです。クラスを作成し、予測可能な方法でその動作と相互作用をモデリングするためのデザインまたはテンプレート

家を見てください。それらにはいくつかの類似点があります。すべての家には最低限、リビングルーム、キッチン、ベッドルーム、バスルーム、トイレがあります。誰もトイレなしで家を建てることはないでしょう？アパートメントには、バンガローとは異なるパターンがあります。城にはまったく異なるパターンがあります。服にもパターンがあります。ジャケットとフォーマルシャツはどちらも基本的なデザインは同じですが、動作は異なります。インタビューではカウボーイジャケットを着用しません。同様に、クラスとそのアクションは、動作とデザインに従ってグループ化できます。動作の共通要素を見ると、クラスのパターンを設計できます。

私が理解している設計パターンは、再利用性と拡張性が主な関心事である場合にのみ重要です。小さなアプリ（たとえば、10個未満のクラス）を作成する場合、まったく必要ない場合があります。しかし、大規模なプロジェクト、特に大規模なチームが作業していて、メンテナンスと機能の追加サイクルが長いプロジェクトでは、必ずパターンが必要になります。大規模なプロジェクトではオプションではありません。

パターンに関するオンラインチュートリアルをご覧ください。ウィキペディアには充実した記事があります。このサイトも良いです：http : //sourcemaking.com/。あなたが経験豊富なプログラマーなら、いくつかのパターンに出くわすことに気付くでしょう。特定の名前でそれを知らずに自分で似たようなものを実装することもできます。

それらを完全に無視しないでください！今ではないのに、将来役に立つかもしれません。心を開いてデザインパターンにアプローチするための鍵は、「デザインパターンを使用しないとどうなりますか？」と尋ねることです。パターンは「キュア」を意味するものではありません（ただし、問題の解決策として使用できます）。むしろ、彼らは「予防は治療よりも優れている」という言葉を具体化している。

それでも、パターンを使用するための小さな口実を見るたびに、パターンを実装することに執着しないように注意します。あるプロジェクトでこの問題に直面しました。アーキテクトは、DPがなければプロジェクトは完全な災害になると確信していました。私たちはグループミーティングを開催し、エンジニアは設計を変更し、彼が推奨する多くのパターンは「すごい美しいパターンを見て」と表示する以外にはまったく役に立たないことを指摘しました。パターンを必要なだけ使用する場所の数を減らすには、多くの説得力と交渉が必要でした。

答えた人々は、通常考えられているように、「パターンベースのプログラミング」に関して正しいです。私は自分がやっていることにもっと関連があると少し違う定義を持っているので、私は「パターンベースのプログラミング」を使って計画的なアプローチではなくプラグインのアプローチを説明する傾向があります。

私はjQueryプラグイン、CMSクラウドプラグイン、eコマースプラグインをプログラミングしているため、その観点からの「パターンベースのプログラミング」は、コアテクノロジーと、どのようなユースケースが存在し、最も統計的に関連するものを調べることを意味します。特にプラグインは非常にパターンベースでなければならないため、プログラミングのコンテキストにうまく適合します。

ただし、複数のプロジェクトで有効なユースケースが表示された後にパターンを適用することをお勧めします。これにより、再利用に関して統計的に有効になります。