現在、デザインパターンは本当に重要ですか？
私は "Coders at Work" を読んでいて、本でインタビューした専門家の一部はデザインパターンにそれほど熱心ではないという事実に直面しました。
これには主に2つの理由があると思います。
デザインパターンは私たちに彼らの言葉で考えることを強います。言い換えれば、何か新しいものを（おそらくより良いものを）発明することはほとんど不可能です。
デザインパターンは永遠に続くわけではありません。言語と技術は急速に変化します。したがって、設計パターンは最終的には無関係になります。
したがって、特定のパターンなしで適切にプログラムする方法を学習し、それらを学習しないことがより重要かもしれません。
重要なのは、通常、人々が問題に直面し、時間があまりないときに、パターンを使用しようとすることです。これは、コードを機能させるために、マイナーな変更を加えて既存のコードをプロジェクトにコピーして貼り付けることを意味します。何かを変更したり追加したりするとき、それは自分のコードではないため、開発者はどこから始めればよいかわからず、熟知していません。
私のお金としては、誰もがデザインパターンのポイントを逃していると思います。特定の状況でどのパターンを使用すればよいのかと思って座っていることはまれです。また、名前がわかるまでは、ほとんどのパターンを使用していました。
デザインパターンの力はコミュニケーションにあります。私が提案していることを詳細に説明するよりも、「そのための戦略を使用する」と言う方がはるかに迅速です。 2つの用語の意味をすべて知っている場合、ファットドメインモデルとトランザクションスクリプトの利点を議論する方がはるかに簡単です。等々。
そして、最も強力なのは、クラスにFooBuilderという名前を付けた場合、Builderパターンを使用してFooを生成していることです。
「オブザーバーパターンはそのために理想的です」と言ったとき、私が何を話しているのかわからなくても、簡単にグーグルでググることができます。
その意味で、デザインパターンの力が衰えることはありません。
パターンは2つの主要な目的を果たします。
予想通りに緊張を解決する：パターンは、機能することがわかっている方法で、特定の緊張のセットを解決するように設計されています。 Smalltalkベストプラクティスパターンの作者であるケントベックは、専門家が同様の状況で行う決定を繰り返す方法としてパターンについて説明しています。緊張が同じままである限り（そして緊張が同じである限り）、緊張を解決するパターンは引き続き有用です。
通信力の乗数：パターンを使用すると、少しで多くのことを言うことができます。それらは、さまざまな問題空間に適用できる強力でよく理解された概念の小さなセットを活用します。 @pdrの答えは、パターンの伝達的価値については完全に解明されていません。
デザインパターンがイノベーションを妨げるという肯定は完全に誤りです。車輪を再発明する必要がないように、すでに存在する場所を知っておく必要があります。一時的なため、パターンは全体としてOOPシステムに適用され、特定のプラットフォームや言語にリンクされていません。
さて、私がパターンについて話すときに嫌いなのは、一部の人々はある種のこだわりを持っているということです。かつて、クライアントに「少なくとも2つのパターンを含めるように」（WTF ?!）と尋ねてきたことがあります。コードに流行語がないために、十分にエンタープライズに見えなかったためです。
たぶん anti-patterns の概念は密接に関係しています。ソフトウェアエンジニアになるための重要なステップとして、デザインパターンを学ぶことは考えていません。ソフトウェア設計は重要であり、多くの場合、プロジェクトのソフトウェアアーキテクトの特権として確保されますが、現実的には、よく知られている「よくゲル化された」チームのコンセンサスによって打ち出すことができるものです。
しかし、デザインパターンとアンチパターンはそれらの議論のリソースを形成します。うまく機能した（または機能しなかった）ことの教訓、および設計の選択の結果をどのように活用（または軽減）するかを理解する必要があります。優れたチームcouldそのような議論のために独自の語彙を考え出しますが、そこに行った作者が作成した事実上の標準を参照することは、それほど悪いことではありません。
デザインパターンには次の2種類があります。
- ユニバーサルパターン。これは、複雑なプログラムを整理して、まったく理解できるようにする方法の詳細です。これらはなくなることはありませんが、さらに多くの例が発見される可能性があります。
- 状況パターン。これらは、制約（プログラミング言語など）によって引き起こされる特定の力に拘束されているため、これらの力が変化すると、それらは無関係になります。
確かに、すべてのパターンは状況によって多少異なりますが、一部の力は実世界からのものであり、他の力はツールからのものです。ツールは、現実の世界よりもはるかに速く変化します。
デザインパターンについて読むことは、数学を再発明するのではなく、数学を学ぶようなものです。以前に何が起こったのかをしっかりと理解すれば、特定の分野で大きな進歩を遂げることを妨げるものはありません。リーマンはユークリッドを決して読んだことがないと思いますか？
同僚や顧客が「これはどのように機能するのか？」標準化のために標準を強制する意味はありませんが、何かを行うための一般的でよく知られている方法が1つあれば、コーダーがそのパターンを探してそれを期待し、それを実行するたびに、あなたと彼らの仕事が完了します。より簡単に。
4人一組がデザインパターンを次のように分類していると思います。
よく発生する問題の一般的な解決策*
つまり、同じタイプの問題が発生した場合、パターンは適切です。これにより、「デザインパターン」という用語に問題が生じます。パターンは、繰り返し発生する認識可能なものです。したがって、実際にはデザインのパターンはなく、問題のパターンがあります。
一部のプログラミング言語には、これらの問題の一部に対するネイティブソリューションがある場合があります。 "Design Patterns"本自体は、CLOSを使用している場合、ビジターパターンはほとんど価値がないと述べています。マルチディスパッチはCLOSによってネイティブにサポートされているため、ビジターパターンが解決しようとしている問題そのものです。
また、.NETフレームワークには、複数のリスナーにイベントを発行するための組み込みのイベントメカニズムがあり、このコンテキストではObserverパターンの関連性が低くなります。
デスクトップアプリケーションからWebアプリケーション**への変更は、私たちが解決しなければならないプログラミング問題のタイプも変更します。本「Design Patterns」のパターンの多くはデスクトップアプリケーションに関連していますが、Webアプリケーションにはあまり関連していません。もちろん、単一ページのアプリの場合、これらのパターンはクライアント側でも関係があるかもしれません。
しかし、デザインパターン、および「デザインパターン」や「エンタープライズアプリケーションアーキテクチャのパターン」などの本は、初心者プログラマであり、初めて新しいタイプの問題に直面したときに非常に価値があります。元に戻す機能を実装するように依頼されたのは初めてだったので。 「デザインパターン」の本がなかったとしたら、私の実装はおそらく、状態変更操作ごとにデータのスナップショットを保存するようなものでした***-非常にエラーが発生しやすく、恐ろしく非効率的なアプローチです。
そのため、はい、パターンの一部は時間の経過とともに関連性が低くなり、経験豊富なプログラマーになると、それらについてあまり考えなくなります。しかし、初心者にとっては、問題を解決する手段であり、できるだけ多くを使用するための探求ではないことを覚えている限り、それらは貴重です。
*引用はメモリから取得されるため、100％正確ではない場合があります
**私の経験では、企業が内部の基幹業務アプリケーション用のWeb配信メカニズムを選択することは非常に一般的になっています。
***関数型プログラミングと関数型データ構造を学んだ後、それが実際に私が今日解決する方法かもしれません。