パターンベースのプログラミングとは何ですか？
誰かがプログラミングにおけるパターンとアンチパターンへの執着を説明できますか？どんなパターンが何を意味するのか全くわからないので私は尋ねます。プログラミングタスクに直面したとき、問題について少し考え、関連があると思われるデータ構造をいくつか書き留め、ソリューションのプロトタイプを作成し、いくつかのモジュールを分離して繰り返します。プロセスのどこにも「ああ、ここにはFunkyLookyTasticパターンが必要だ」とは思いません。
パターンは、一般的なタイプの問題を解決するための一般的なアプローチです。それ以上、それ以下ではありません。それらを知って理解することにより、他の人の経験を利用して、うまく機能することが示されている種類のソリューションに導き、過去に遭遇した落とし穴を回避し、他の人に馴染みのある用語を使用してソリューションについて話し合うことができますそのパターンを知っています。
もちろん、明示的にパターンを使用せずに細かい解決策を考え出すこともできますし、特定の問題に実際には適合しないパターンを適用しようとすることによって、同様に悪い解決策を考え出すこともできます。あなたが見ている「執着」は、一般にその概念を発見したばかりの人からのものであり、実際よりもかなり強力だと思います。ほとんどの人は、それらが何であるかをすぐに認識します。魔法の弾丸ではなく、便利なツールです。
一方、アンチパターンは、コード品質を低下させる傾向がある一般的に観察される動作です。繰り返しになりますが、これらのいくつかを知って理解しておくと、そのような動作を回避し、他の動作でそれを観察したときに、それを（正当な引数を使用して）修正することができます。パターンの使いすぎをアンチパターンと表現する人もいます。
パターンは、クックブックでプログラマーが抽出した知識であり、プログラマーが通信するための便利な方法でもあります。
他の回答が示唆しているように、パターンは本当に一般的な問題の一般的な解決策です。利点は、コーディングを開始する前に、既存のパターンを使用したり、予想される落とし穴を発見したりすることで、より良いソリューションを得ることができることです。
他の利点は、コードについて誰かと話しているときです。パターンは、長い説明をいくつかの単語に要約する別のタイプの専門用語です。パターンに言及せずに「工場にオブザーバーが追加された」と説明してみてください。できますが時間がかかります。
ほとんどの開発者は、入ってくる新しいパラダイムや方法論にうんざりします。私が最初にデザインパターンについて聞いたとき、そうしました。デザインパターンは、その名前が示すとおりです。クラスを作成し、その動作と相互作用を予測可能な方法でモデル化するためのデザインまたはテンプレートです。
家を見てください。それらにはいくつかの類似点があります。すべての家には、リビングルーム、キッチン、ベッドルーム、バスルーム、トイレがあります。誰もバスルームなしで家を建てませんよね？アパートは、バングラとは異なるパターンを持っています。城はまったく異なるパターンを持っています。服にもパターンがあります。ジャケットとフォーマルシャツはどちらも基本的なデザインは同じですが、動作は異なります。面接ではカウボーイジャケットを着用しません。同様に、クラスとそのアクションは、それらの動作と設計に従ってグループ化できます。動作の共通要素を見ると、クラスのデザインパターンがわかります。
私が理解している設計パターンは、再利用性と拡張性が主な関心事である場合にのみ重要です。小さなアプリ（たとえば10クラス未満）を作成する場合、それらはまったく必要ない場合があります。ただし、大規模なプロジェクト、特に大規模なチームで作業し、メンテナンスと機能の追加サイクルが長いプロジェクトには、必ずパターンが必要です。大規模なプロジェクトでは、これはオプションではありません。
パターンに関するいくつかのオンラインチュートリアルをご覧ください。ウィキペディアには一連の優れた記事があります。このサイトも良いです： http://sourcemaking.com/ 。あなたが経験豊富なプログラマーであれば、いくつかのパターンに出くわしたことに気づくでしょう。特定の名前でそれを知らなくても、同様の何かを自分で実装したかもしれません。
それらを完全に無視しないでください！現在ではないにしても、将来的には役立つでしょう。オープンマインドでデザインパターンに取り組むための鍵は、「デザインパターンを使用しないとどうなりますか？」パターンは「修正」を意味するものではありません（問題の解決策として使用できます）。むしろ、彼らは「予防は治療よりも優れている」という口実を具体化しています。
いずれにせよ、パターンを実装することへの執着に対しては、それを使用するための小さな口実が見られるときはいつでも警告します。この問題に直面したのは、DPがなければプロジェクトは完全な災害になると建築家が確信している1つのプロジェクトでした。グループミーティングでエンジニアがデザインを変更し、彼が推奨した多くのパターンは「美しいパターンを見て」と表示する以外にまったく役に立たないことを指摘しました。パターンが必要な場所にのみ使用される場所の数を減らすには、多くの説得力といくつかの交渉が必要でした。
答えた人々は、通常考えられている「パターンベースのプログラミング」に関しては正しいです。私がやっていることとの関連性が高いとは少し異なる定義があり、計画アプローチではなくプラグインアプローチを記述するために「パターンベースのプログラミング」を使用する傾向があります。
私はjQueryプラグイン、CMSクラウドプラグイン、eコマースプラグインをプログラミングしているので、その観点からの「パターンベースのプログラミング」とは、コアテクノロジーとどのような使用例が存在するかを調べ、最も統計的に関連性の高いものにヒットすることを意味します。特にプラグインは、プログラミングコンテキストにうまく適合するように、非常にパターンベースである必要があります。
ただし、複数のプロジェクトで有効なユースケースが表示された後でパターンを適用することをお勧めします。これにより、パターンは統計的に再利用できます。