デザインパターンを活用することの重要性は常に認識してきました。他の開発者が最も適切なものをどのように選択するかについて興味があります。一連の特性(フローチャートなど)を使用して判断を下していますか?
例えば:
オブジェクトが関連しているが具象クラスを指定したくない場合は、抽象を検討してください
インスタンス化を派生クラスに任せる場合は、ファクトリを検討してください
集計オブジェクトの要素に順番にアクセスする必要があります。イテレータを試してください
または類似の何か?
今日のコーディングの世界における重要な誤解は、パターンは構成要素であるということです。ここでAbstractFactory
を、そこにFlyweight
を、そしておそらくSingleton
を向こう側に、それらをXMLとprestoで接続すると、アプリケーションが動作するようになります。
そうではありません。
うーん、それは十分に大きくありませんでした。
それは良いです。
パターンは、問題が発生したときに使用するものです。パターンが提供する柔軟性が必要です。または、構成ファイルで少し言語を作成していて、「待機」と言ったときに偶然見つけたものです。ちょっと待ってください、これは私が書いている独自のインタープリターです-これは既知の解決済みの問題です。 インタープリターパターン を使用してください。」
ただし、コード内でdiscoverするものであり、最初からではないことに注意してください。 Java=の作成者は、最初に「ああ、フライウェイトを整数に入れる」とは言っていませんでしたが、むしろパフォーマンスの問題に気づきましたflyweight によって解決されました。
したがって、正しいパターンを見つけるために使用する「フローチャート」はありません。パターンは、特定のタイプの問題が繰り返し発生し、その主要な部分がパターンに抽出されたソリューションです。
パターンから始めるのは、解決策を見つけて問題を探すようなものです。これは悪いことです。それは過剰なエンジニアリングにつながり、最終的には設計の柔軟性に欠けます。
コードを記述しているときに、ファクトリを記述していることに気づいたら、「ああ、これはこれから書くファクトリです」と言って、ファクトリパターンを理解している知識を利用して、次のビットをすばやく記述できます。 Factoryパターンを再発見することなくコードを記述します。しかし、「ここにクラスがあるので、柔軟性を持たせるために、そのためのファクトリーを作成します」から始めないでください。
Erich Gammaのインタビューからの抜粋です( Gamma、Helm、Johnson、Vissides ): デザインパターンの使用方法 :
すべてのパターンを使おうとするのは悪いことです。合成設計、つまり誰も必要としない柔軟性を備えた投機的な設計になってしまうからです。最近のソフトウェアは複雑すぎます。他に何をすべきかを推測する余裕はありません。私たちは本当にそれが必要とするものに焦点を合わせる必要があります。そのため、パターンへのリファクタリングが好きです。人々は、特定の種類の問題やコードのにおいがある場合、最近ではそれを呼び出すように、パターンツールボックスに移動して解決策を見つけることができることを学ぶ必要があります。
「何をいつ使用するか」の最良のヘルプは、おそらくWikipediaのページ ソフトウェア設計パターン です。「分類とリスト」セクションでは、各パターンのカテゴリとその機能について説明しています。フローチャートはありません。その説明は、「何をいつ使用するか」の短いスニペットとして見つけるのに最適です。
プログラミングのさまざまな領域でさまざまなパターンが見つかることに注意してください。 Webデザインには独自のパターンのセットがあり、JEE(Webデザインではない)には別のパターンのセットがあります。財務プログラミングのパターンは、スタンドアロンアプリケーションのUIデザインのパターンとは完全に異なります。
したがって、それらをリストする試みallは本質的に不完全です。あなたはそれを見つけて、それをどのように使用するかを理解し、最終的にそれは第二の性質となり、(誰かがそれを説明するように要求するまで)いつどのように使用するかについて考える必要はありません。
自分自身に問う:
ソフトウェアパターンを選択するプロセスは、データ構造を選択するプロセスと異なりません。ただし、データ構造を選択する場合は、問題のパフォーマンスとメモリ特性を評価し、データ構造を選択します。それらの特性に最もよく適合します。