デザインパターンの使い方に関しては、3つのタイプのお店があると思います。直面した場合にパターンを知らない人 - これらは通常、コードを再利用するために Ctrl-C / Ctrl-V アプローチを好みます。もう 1 つの優れたパターンを実装することを期待して、レガシー コードの検索に 1 日に何時間も費やす人 - これらは通常、単純なプログラムのコードのリファクタリングに、100 年のメンテナンスに費やされるよりも多くの時間を費やします。そして最後に、意味のある場合はパターンを使用し、コードの露出を最小限に抑えるために最初に来るものは何でもコーディングする、中間の道を歩む人たちです。
ソフトウェア開発のライフ サイクルにパターンの使用をバランスよく組み込むための優れたアプローチを確立した人がいるかどうか疑問に思っています。また、パターン、その動機となる要因、およびそれらの適切な使用について、Web で最も優れたリソースは何ですか?
ありがとう。
そこにはさまざまな「パターン」ファミリーがたくさんありますが、あなたの質問を最も広い用語で取り上げると...
私はお勧めします：
オフライン (私のお気に入り):
オフライン (ポピュラー):
パターンを適切に使用するには、知識と経験が必要です。それには公式はありません。パターンを慎重に適用する経験のある人に、チーム内の他の全員のコードを定期的にレビューしてもらい、デザイン パターンを使いすぎたり、使いすぎたりしていないことを確認することをお勧めします。それらは事前に焼き上げられたレシピではありません-効果的に適用するにはスキルが必要であり、それを習得する必要があります.
私が最初にデザイン パターンに触れたのは、Portland Pattern Repositoryでした。
「パターン」の使用は、以下に大きく依存します。
デザインパターンは、C++、Java などの言語で過大評価されている可能性があります。それらは、あらゆる種類のタイピングの問題で導入される柔軟性のなさを隠します。制限の少ない言語でどのパターンが「生き残る」かについてのリンクは次のとおりです: http://norvig.com/design-patterns/
もう 1 つの例は、アスペクト指向プログラミングです。このプログラミングでは、そのために「設計」されていない言語で物事が「導入」される可能性があります。
使用するツールの背後にある哲学も大きな影響を与えます。Smalltalk、Common Lisp、Haskellなどの平均的なPHPまたはVisual Basicプログラムとソリューションを比較してみましょう。
構文要素も大きな影響を与えます。C や C++ (イテレータ) など、同様のループがたくさんありますが、高階関数をサポートする言語を調べると、いくつかのループが見つかるだけです。
次に、人々がプログラミングにアクセスする方法、ボトムアップまたはトップダウン、断片的な成長またはピラミッドの構築、またはその他の個々の好みを確認する必要があります。
上記のリンクを読んでから、「異なる」言語での実装を確認することをお勧めします....
よろしく フリードリヒ
Refactoring: Improving the Design of Existing Codeをお勧めする必要があると思います。
(出典: 2020ok.com )
パターンの賢明な使用法を実装する方法の例がたくさんあります。
パターンとリファクタリングに関する情報を含む最高の Web リソースだと思います - http://sourcemaking.com
誰もが常にパターンを使用しています。彼らはそれを知らないだけかもしれません。「リストの繰り返し」のような単純なことでさえ、パターンです。
パターンを作業サイクルに組み込む最善の方法は、パターンを使用し、それらについて議論するときやコードにコメントするときに名前で参照することだと思います。うまくいけば、これは知識の拡散につながります。
たとえば、あなたがやっていることは Observer にぴったりだと気づいたとしましょう。あなたは同僚に「ねえ、このオブジェクトをオブザーバーにして、このオブジェクトをサブジェクトにすれば、これは本当に簡単にできるよ」と言います。
同僚がすぐに理解するか (パターンが時間の節約になります)、またはあなたが同僚を教育して、次にObserver について言及したときに同僚がすぐに理解するかのどちらかです。
同時に、知識を広めることで、彼らはあなたから学んだ新しいパターンを使用する機会を見つけます。もちろん、これは双方向です。次回は、新しいパターンを教えてくれるかもしれません。
これはすべて、あなたの同僚が、理解していないときにうなずいたり、理解しているふりをしたりするタイプではないことに依存しています。「ねえ、あなたはオブザーバーについて言及しましたが、それが何であるかはわかりません」と言う必要があります。
私はこのシリーズの大ファンで、彼らの本をたくさん読んでいるので、Head First Design Patternsをお勧めします。O'Reilly のSafari Bookshelfからオンラインで読むことができますが、ハード コピーには素晴らしいパターンのポスターも付属しています。
上記のコメントにこれ以上同意できませんでした。私はできる限りデザイン パターンを使用しますが、特定のパターンの利点を真に理解するために常にチームの他のメンバーに頼っています。そうしないと、見苦しいコードと、パターンに多少似た軽量のラッパーになってしまいます。
余談ですが、 http: //www.developer.com には、デザイン パターンとそのアプリケーションに関する記事が毎月数回掲載されています。幸運を！
定義と元の答えは、設計パターンの概念の起源です。この本は、この分野に浸透した経営陣の話ではなく、非常に理論的なレベルで概念を扱っています。彼らの見解は、設計パターンは一般的なイディオムの名前に過ぎないというものです。彼らはいくつかを列挙し、彼らの立場を正当化します。
彼らは「どのデザインパターンを使えばいいのか」というタイプの質問を避け、代わりに「私はよく知られている領域に自然に足を踏み入れていますか? もしそうなら、他の経験者は私を助けてくれますか?」というような問題に対処します. 私にとって、デザイン パターンは、ソリューションを作成するために接着するプレハブ コンポーネントのようなものではありません。それらは、他の人が反論した状況に似た状況に遭遇したときのガイダンスリポジトリであり、人々が会話で一般的な状況を参照できるように名前を付けます.
適用可能なパターンを完全に理解して初めて、パターンをどこで使用するかがわかるという点で、デザイン パターンは面白いものです。ストラテジー、オブザーバー、イテレーターなどは、少し練習すれば、あまり深く考えずに使用できます。C# を使用している場合は、反復子をパターンとして考えずに常に (IEnumerable...) 使用します。
私の意見では、これらの単純なパターンが最良のパターンです。すでにやらなければならない仕事があり、問題がうまく収まらないときに問題を次から次へと押し込もうとするのは時間の無駄であり、結果として悪いコードになります。
私のアドバイスは、UML ダイアグラムでパターンを確認することです。それがかなり単純な場合は、後で思い出せるように十分に学習してみてください。単純なコントラクトを持つパターンは、より頻繁に役立つ可能性があります。
私はギャング・オブ・フォーのデザイン・パターンの本と一緒に行きます
私はこれらの参照に同意しますが、初心者に優しいわけではありません. 簡単な方法で設計パターンの学習をすばやく開始するには:
次に、全体像を把握したら、より高度な本を確認できます（多くの実用的な例;-)）
