最近のデザインパターンは本当に重要ですか？

私は「Coders at Work」を読んでいて、この本でインタビューした専門家の中には、デザインパターンにあまり熱心ではないという事実に直面しています。

これには主に2つの理由があると思います。

1. 設計パターンは、その用語で考えることを私たちに強制します。言い換えれば、何か新しいものを発明することはほとんど不可能です（たぶん良いでしょう）。

2. 設計パターンは永遠に続きません。言語とテクノロジーは急速に変化します。したがって、設計パターンは最終的には無関係になります。

したがって、特定のパターンなしで適切にプログラミングする方法を学習し、それらを学習しないことがより重要かもしれません。

ポイントはまた、通常、人々が問題に直面し、あまり時間がないときに、パターンを使用しようとすることでした。これは、既存のコードをコピーして貼り付けて、わずかな変更を加えてプロジェクトを機能させることを意味します。何かを変更したり追加したりするとき、開発者は自分のコードではなく、深く理解していないため、どこから始めればよいかわかりません。

私のお金のために、私は誰もがデザインパターンのポイントを逃していると思います。特定の状況でどのパターンを使用する必要があるのか​​疑問に思うことはめったにありません。また、これらのパターンのほとんどは、名前がわかるまでずっと使用していました。

デザインパターンの力はコミュニケーションにあります。私が提案していることを詳細に説明するよりも、「そのための戦略を使用する」と言う方がはるかに迅速です。これら2つの用語の意味がわかっている場合、ファットドメインモデルの利点とトランザクションスクリプトの利点を議論する方がはるかに簡単です。等々。

最も強力なのは、クラスにFooBuilderという名前を付けた場合、Builderパターンを使用してFooを生成していることです。

「オブザーバーパターンが理想的です」と言ったときに、私が何を言っているのかわからなくても、簡単にそれをグーグルで検索できます。

その意味で、デザインパターンの力は衰えることはありません。

設計パターンは、ソフトウェアの人間として使用する共通言語の表現力の向上です。この共通言語は必須ではありませんが、問題の多くの一般的な解決策を簡単かつ迅速に表現できます。たとえば、シングルトンについては、「インスタンスを1つだけ持つはずであるが、静的でグローバルにできないクラス」について話すよりもはるかに簡単です。

設計パターンが提供するソリューションは有用ですが、それらが解決する問題に直面した場合、おそらく既に考えたソリューションです。設計パターンを理解するには、ある程度の成熟度が必要です。問題を解決する必要がなかった場合、そのソリューションの価値や関心はわかりません。

パターンには2つの主な目的があります。

• 緊張を予想通りに解決する：パターンは、機能することが知られている方法で特定の緊張のセットを解決するように設計されています。Smalltalk Best Practice Patternsの著者であるKent Beckは、同様の状況で専門家が下す決定を繰り返す方法としてパターンを説明しています。緊張が同じままである限り（そしてしばしば緊張する）、それらを解決するパターンは有用なままです。

• コミュニケーション力の乗数：パターンにより、少しだけ多くのことを言うことができます。それらは、さまざまな問題空間に適用できる、強力でよく理解された少数の概念を活用します。@pdrの答えは、パターンの伝達価値については行き詰まっています。

設計パターンがイノベーションを妨げるという肯定は完全に間違っていると思います。すでに存在する場所を知っておく必要があるので、車輪を再発明する必要はありません。一時的であるため、パターンは全体としてOOPシステムに適用され、特定のプラットフォームまたは言語にリンクされません。

さて、人々がパターンについて話すとき私が嫌いなのは、一部の人々がパターンに執着しているということです。かつて「少なくとも2つ以上のパターンを含めるように」（WTF ?!）を依頼するクライアントがいました。これは、コードに流行語がないために、エンタープライズに十分に見えなかったためです。

おそらく、アンチパターンの概念は密接な関係にあります。設計パターンを研究することは、ソフトウェアエンジニアになるための重要なステップとは考えていません。ソフトウェア設計は重要であり、多くの場合、プロジェクトのソフトウェアアーキテクトの特権として留保されますが、現実的には、よく知られた「よくゲル化された」チームのコンセンサスによって打ち出されるものです。

しかし、デザインパターンとアンチパターンは、これらの議論のリソースを形成します。うまくいった（またはうまくいかなかった）ことの教訓と、設計選択の結果を利用する（または軽減する）方法を理解する必要があります。優れたチームは、そのような議論のために独自の語彙を考え出すことができますが、実際にそこに行った著者によって作成された事実上の標準を参照するのはそれほど悪いことではありません。

デザインパターンには次の2種類があります。

1. 普遍的なパターン。複雑なプログラムを整理して、理解できるようにする方法について詳しく説明しています。これらの例は今後も発見される可能性がありますが、消えることはありません。
2. 状況パターン。制約（プログラミング言語など）によって誘発される特定の力に拘束されるため、それらの力が変化すると、それらは無関係になります。

確かに、おそらくすべてのパターンはやや状況的なものですが、一部の力は現実の世界からのものであり、他の力はツールからのものです。ツールは、実世界よりもはるかに速く変化します。

デザインパターンについて読むことは、数学を再発明する代わりに数学を学ぶようなものです。前に何が起こったのかをしっかりと理解すれば、特定の分野で大きな進歩を遂げることはできません。リーマンはユークリッドを読んだことがないと思いますか？

同僚や顧客が「これがどのように機能するのか」と考える時間を短縮する場合、パターンを設計する利点があります。標準化のために標準を実施する意味はありませんが、何かを行うための一般的で十分に理解されている方法があれば、コーダーがそれを見つけることを期待してそのパターンを探すたびに、あなたは彼らとあなたの仕事をしましたより簡単に。

私は4人のギャング自身がデザインパターンを

一般的に発生する問題に対する一般的なソリューション*

そのため、同じ種類の問題が発生した場合にパターンが関連します。そして、これは「デザインパターン」という用語の問題につながります。パターンは、繰り返し発生する認識可能なものです。したがって、実際にはデザインのパターンはなく、問題のパターンがあります。

一部のプログラミング言語には、これらの問題のいくつかに対するネイティブソリューションがあります。「デザインパターン」の本自体は、CLOSを使用している場合は訪問者パターンはほとんど価値がないと述べています。マルチディスパッチはCLOSによってネイティブにサポートされているためです。

また、.NETフレームワークには、複数のリスナーにイベントを発行するためのイベントメカニズムが組み込まれているため、このコンテキストではObserverパターンの関連性が低くなります。

デスクトップアプリケーションからWebアプリケーション**への変更は、解決しなければならないプログラミングの問題の種類も変更します。「Design Patterns」という本のパターンの多くは、デスクトップアプリケーションに関連していますが、Webアプリケーションにはあまり関係していません。もちろん、単一ページのアプリでは、これらのパターンはクライアント側でも再び関連する可能性があります。

しかし、デザインパターン、および「デザインパターン」や「エンタープライズアプリケーションアーキテクチャのパターン」などの本は、初心者のプログラマーであり、初めて新しいタイプの問題に直面したときに大きな価値があります。元に戻す機能を実装するように求められたのは初めてでした。「デザインパターン」の本がなかったら、私の実装は、おそらく、状態が変化する操作ごとにデータのスナップショットを保存するようなものだった***-非常にエラーが起こりやすく、ひどく非効率的なアプローチです。

確かに、パターンの一部は時間の経過とともに関連性が低くなり、経験豊富なプログラマーになると、それらについてあまり考えなくなります。しかし、初心者にとっては、問題を解決するための手段であり、できるだけ多く使用するための探求ではないことを覚えている限り、貴重です。

*引用はメモリから取得されるため、100％正確ではない場合があります

**私の経験では、企業が内部の基幹業務アプリケーションにWeb配信メカニズムを選択することは非常に一般的になっています。

***関数型プログラミングと関数型データ構造を学んだ後、それが実際に今日それを解決する方法になるかもしれません。

設計パターンへの奴隷的な順守は有害である可能性があります-パターンは一般的な問題に対する文書化された解決策ですが、それらは取扱説明書ではありません。ただし、それらが詳細に議論され、場合によっては効果的な問題領域の外側に適用されたからといって、それらがまったく価値を持たないということにはなりません。それらは、フレームワークと呼ばれる一連の原則であり、プログラムのアーキテクチャを設計するときに活用することで、アーキテクトがソリューションの動作をどのように見たいかを印象付けることができます。優れた開発チームは、それらを機能仕様ではなく機能の基礎と見なしています。