私は大学生で、デザインパターンについて学び始め、デザインパターンの目的を理解するのに苦労しています。私はそれらを研究しようとしましたが、私が見つけたすべてのリソースは、専門的ではなく学術的な方法でそれらについて話しているようです。
彼らの目的は何であり、学ぶことは重要ですか?
私は大学生で、デザインパターンについて学び始め、デザインパターンの目的を理解するのに苦労しています。私はそれらを研究しようとしましたが、私が見つけたすべてのリソースは、専門的ではなく学術的な方法でそれらについて話しているようです。
彼らの目的は何であり、学ぶことは重要ですか?
回答:
設計パターンは、意図を非常に迅速に伝えるのに最適です。誰もがファクトリーを知っています。
本当に、本当に、本当に悪いことは、コードをパターンに適合させようとすること、またはパターンに応じて責任を分離すること、またはそのようなことを始めることです。「このオブジェクトはファクトリーです」と言うことと、「このオブジェクトはファクトリーのみでなければなりません」と言うことです。
設計パターンに関するウィキペディアの記事から:
パターンについて話すことの有用性は、デザイナーがすでに何度も見ている状況を議論するための共通の用語を持つことです。
非常に長い間、ソフトウェアエンジニアリングに深刻な問題がありました。プロジェクトの新規参入者を雇い、彼らがプログラミング言語をどれだけよく知っていても、あなたの仕事がどのように行われているかを把握するには数ヶ月かかります生産性を高める前にプロジェクトを作成します。ハードウェアエンジニアリングでは、かなり前にこの問題を解決しました。「回路図」と呼ばれる共通の用語があります。ハードウェアエンジニアを雇い、午前中にハードウェアプロジェクトの回路図を渡して、彼らに研究させ、そして夕方までにそれを呼び出す時間になる前に、はんだ付けガンを拾って生産性を上げることができます。私たちはそれを改善する方法を考え出そうとしています。プログラミング言語の標準化は1つの方法でした。標準ライブラリ(最近のクラスライブラリ)は別の方法です。しかし、最も重要な方法の1つはおそらくデザインパターンです。それで、彼らは重要ですか?あなたは賭けます!
パターンの存在には、2つの異なる実質的な理由があります。
最初の方法はすでに十分に説明されています。パターンを使用すると、開発者間のコミュニケーションが円滑になります。あなたと私は、「オブザーバー」と言うとき、私は非常に特定のコード構造について話していることを理解している場合、そのパターンを使用するコードのビットがどのように機能するかを非常にすばやく説明できます。別の方法は、ソリューションを完全に記述することです。これは、時間がかかり、エラーが発生しやすくなります。(「まあ、私は消費者オブジェクトを記述してインターフェースするこの純粋な仮想クラスを作成し、アクティブな消費者のリストを保持するクラスを作成しました...」)
パターンの2番目の利点は、一般的な問題の形式に対する既製のソリューション形式であることです。パターンを知っていて、たとえば、クラス間の不要な結合を導入せずに、(おそらく複数の)プロデューサーオブジェクトから複数のコンシューマオブジェクトに情報を取得するための適切な方法を見つける必要があるという問題に遭遇した場合、オブザーバーの仕事です!」問題を解決する方法がすぐにわかります。
これらの利点は、お互いを本当に強化します。これらを使用すると、特定の一般的なクラスの問題を迅速に解決でき、完了したら、問題の解決方法を非常に迅速に伝えることができます。
これを、パターンが「存在しない」世界と比較してください。これらのクラスの問題の1つに遭遇しますが、これは一般に些細な設計問題ではなく、かなりの時間をかけて適切な解決策を考え出します(偶然にも、適切なパターンに非常によく似ています)。その後、同僚が現れて、あなたがそれをどのように解決したかを知りたいと思い、1時間かけてその方法と理由を話し合います。
これはすべて、かなり明白に思われる警告に関連しています。適合しないパターンに問題を強制しようとしないでください。パターンが問題に合わない場合、ソリューションは複雑になり、パターンの労力削減のメリットが失われます。さらに、あなたの仕事は同僚のパターンの意味の理解にもはや適合しないので、コミュニケーションの利益のコストを失うことになります。実際、パターンの誤用は同僚にソリューションに対する誤った理解を与え、まったく理解しないよりも悪いため、パターンなしのコストを超えてコミュニケーションのコストを増やす可能性があります。
パターンとは、アイデアや概念の再利用と、コミュニケーションのための共通/一貫性のあるプラットフォームの確立に関するものです。
理論的にはコードの再利用は良いことですが、実際にはそうするよりも難しいことが判明しています(いくつかの点でこれは変化していますが、常に挑戦的です)。しかし、実際には、再利用したいことの多くは、特定の問題の解決策を構築するために一種のテンプレートを使用すること、つまりパターンです。したがって、問題Xを解決するための良いアプローチは、パターンYを使用することであり、パターンYの要素はa、b、cであり、これから進むことを知っていると言う場合があります。パターンは広く理解されているため、コミュニケーションの利点である詳細を説明する必要はありません。
パターンの面白いところは、言語とフレームワークが進化して、一般的なパターンのサポートが改善され、コードの再利用が増える(レゴブロックが増える!)ため、アプリケーションを構築する方法(パターンを実装することにより) )再利用を促進します。
設計パターンは、あらゆるソフトウェアソリューションが構築される既知のブロックです。これらは、次の理由により重要です。
それらは言語に依存しません。与えられた問題/アーキテクチャ/タスクに適切な設計パターンがわかったら、マルチパラダイム言語(C#、Java、Pythonなど)で実装できます。ほとんどの場合、ソリューションは同じです。構文を調整します。これは、同じ問題ドメイン内(およびドメイン間でさえ)にいる限り、ある言語でのプログラミングから他の言語に経験を移すことができることを意味します。
設計パターンはプログラミングパラダイムにバインドされているという事実にもかかわらず、オブジェクト指向プログラミングの設計パターン(「Gang of Four」パターンとしても知られる最も有名なもの)を意味します。パターンを使用すると、パラダイムが最適なものを理解し、単なる構文を超えることができます。たとえば、C#とJavaで多くの実装を見てきましたが、人々はBasicまたはFortranでプログラミングした方法をプログラムしました-問題を解決するための完璧な命令型の心を持ち、このソリューションをレンダリングするためだけにOOPを使用します-継承はありません、ポリモーフィズムはありません。すべてのメソッドはパブリックなどです。デザインパターンを使用すると、これらの概念の背後を確認し、実際の動作を確認できます。関数型プログラミングのような他のパラダイムの設計パターンにも同じことが当てはまります。
通常、パターンはアイデアを表す便利な方法であり、アーキテクチャからコンピューターサイエンスに導入されました。特定の「パターン」の背後にある考え方を理解すると、他の問題でこのパターンを簡単に認識し、このパターンを使用して解決することができます(問題に対処するためにわずかに変更される可能性があります)。エンタープライズソフトウェア統合、ソースコードテストなど、さまざまなパターンがあります。コンピューターサイエンスの本でパターンを探してください。
パターンを学習することで優れたプラクティスを習得するだけでなく、アンチパターンを学習することで、コードの愚かな間違いを避ける方法を簡単に学ぶことができます。非常に面白いと同時に教育的なアンチパターンの形で、さまざまな分野でよくある間違いを取り上げた本がたくさんあります。ところで、これらのアンチパターンの名前が大好きです!
デザインパターンの有用性は、選択する言語によって異なります。強力な言語を選択するほど、設計パターンを理解して実装する必要が少なくなります。設計パターンは、あなたの言語が組み込みの機能を欠いていることを示すシグナルかもしれません。
Joe Gregorioは、Pythonのデザインパターンの欠如について素晴らしい話をしました