デザインパターン

---

デザイン パターン (デザイン パターン) は、ほとんどの人に知られている、繰り返し使用されるコード設計エクスペリエンスを分類してカタログ化した一連の概要です。デザイン パターンを使用する目的は、コードを再利用し、コードを他の人が理解しやすくし、コードの信頼性を確保することです。デザイン パターンが自分自身、他者、およびシステムにとって Win-Win であることは疑いの余地がありません。デザイン パターンにより、コード作成が真のエンジニアリングになります。デザイン パターンは、建物の構造と同じように、ソフトウェア エンジニアリングの基礎です。

---

デザイン パターン (英語のデザイン パターン) は、オブジェクト指向設計で繰り返し発生する問題の解決策です。この用語は、1990 年代に Erich Gamma らによって建築設計の分野からコンピューター サイエンスに導入されました。この用語の意味には議論の余地があります。アルゴリズムは設計上の問題ではなく問題解決に取り組むため、アルゴリズムは設計パターンではありません。デザイン パターンは通常、相互に密接に連携するクラスとオブジェクトのセットを記述します。デザイン パターンは、ソフトウェア設計について議論するための共通言語を提供するため、熟練した設計者の設計経験を初心者や他の設計者が理解できるようになります。デザイン パターンは、ソフトウェア リファクタリングの目標も提供します。

ソフトウェア開発コミュニティにおけるデザイン パターンへの関心の高まりに伴い、いくつかの関連書籍が出版され、対応するセミナーが定期的に開催され、ウォード カニンガムはデザイン パターンを伝達するために WikiWiki を発明しました。

ヒント: このチュートリアルでは、Java の例を通じてデザイン パターンの概念を段階的に説明します。したがって、Javaknowledge について知っておく必要があります。

表現形式

ソフトウェア設計パターンを表現する形式は、部門や名称など作成者によって異なります。一般的に使用される GoF 記述パターンの形式は、次の部分に大別されます。

• パターン名: 各パターンには独自の名前があり、パターン名を使用して設計について議論できます。

• 問題: オブジェクト指向システムの設計中に、特定のパターンを採用することになる特定の状況が繰り返し発生します。

• 解決策: 上記の問題の解決策。その内容は、設計のさまざまなコンポーネント、それらの関係、責任分担、およびコラボレーション方法を示します。

• エイリアス: パターンには複数の名前を付けることができます。このセクションでは、これらの名前に注意してください。

• 動機: このパターンが使用される場合、このセクションで提供される解決策 (問題とコンテキストを含む) の責任になります。

• 適用性: モデルがどのような状況に適用できるか、モデルの背景など。

• 構造: 一般的に使用されるクラス図と相互作用図のこの部分は、このパターンを示しています。

• 参加者: このセクションでは、このパターンで使用されるクラスとオブジェクトのリストと、それらが設計内で果たす役割を示します。

• 連携: このモードでのクラスとオブジェクト間の対話について説明します。

• 影響: このモデルを採用した場合のソフトウェア システムの他の部分への影響 (システムのスケーラビリティや移植性への影響など)。影響にはマイナスの影響も含まれます。このセクションでは、このパターンを使用した結果、副作用、トレードオフについて説明します。

• 実装: このセクションでは、パターンの実装、パターンに対するいくつかの解決策、およびパターンの実装について説明します。パターンで考えられるテクニック、またはパターンを実装するための提案された方法。

• 例: プログラミング言語でパターンを使用する方法を簡単に説明します。

• 既知のアプリケーション: 業界で知られている実装例。

• 関連パターン: この部分には、他の関連パターンと、他の同様のパターンとの相違点が含まれます。

ヒント: デザイン パターンのチュートリアルは、デザイン パターンのすべてを学ぶのに役立ちます。ご質問がある場合は、PHP 中国語コミュニティ にアクセスして質問してください。熱心なネチズンが答えてくれます。

パターン原則

誰もがデザイン パターンに注目し始めています。では、なぜデザインパターンを使用するのでしょうか?なぜこれほど多くのデザインパターンを使ってデザインする必要があるのでしょうか?

正直に言うと、以前はまったく理解できませんでした。みんなが「デザインパターン」を繰り返しているのを見ているだけで、ちょっと脱力してしまいます。それで、「Gang of Four」のデザインパターンについての本を買ったのですが、まったく理解できていないことがわかりました。読んだときは理解できたように見えましたが、しばらくすると忘れてしまいました。 。たぶんそれは私が比較的「愚か」だからです:)) 最近、私はいくつかの洞察を持っています。 「一緒に幸せになるより、一人で幸せになるほうがいい」ということを皆さんと共有したいと思いますので、アドバイスをいただければ幸いです!

なぜ「デザインパターン」を提唱する必要があるのでしょうか?基本的な理由は、コードを再利用して保守性を高めるためです。

では、コードの再利用を実現するにはどうすればよいでしょうか?オブジェクト指向の世界には、「オープン クローズド プリンシパル」原則、リスコフ置換原則、合成と再利用の原則など、その前任者からのいくつかの原則があります。デザイン パターンはこれらの原則を実装して、コードの再利用を実現し、保守性を高めます。

• オープンクローズ原則

この原則は、「Bertrand Meyer」によって提案されました。原文は「ソフトウェアエンティティは拡張に対してオープンであるべきですが、変更に対してはクローズされている必要があります。」です。つまり、モジュールは拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります。モジュールは、元のコード (元のコードを指す「オリジナル」) を変更せずに拡張するように試行する必要があります。では、どのように拡張すればよいのでしょうか？ 「工場パターン」を見てみましょう: 中関村に海賊版ディスクやポルノ映画を販売する男がいるとします。私たちはその男のために「CD 販売管理ソフトウェア」を設計します。まず「CD」インターフェイスを設計する必要があります。図に示すように: [pre]_____________|<>|| CD ||_____________|| Sell() || ||_____________|[/pre] そして、海賊版ディスクとポルノ映画がそのサブカテゴリです。少年はこれらのディスクを「DiscFactory」を通じて管理している。コードは次のとおりです:

publicclassDiscFactory{
publicstatic光盘
getDisc(Stringname){
return(光盘)Class.forName(name).getInstance();
}
}

海賊版ディスクを購入したい人がいます。どうすればよいですか?

public class 小子{ public static void main(String【】 args){ CD d=DiscFactory.getDisc("海賊版ディスク"); CD.Sell(); } }

ある場合ある日、この男の良心がバレて、正規のソフトウェアを販売し始めました。それは問題ではありません。「正規ソフトウェア」と呼ばれる「CD」の別のサブカテゴリを作成する必要があるだけです。元の構造やコードを変更する必要はありません。どうでしょうか？拡張の場合は開き、変更の場合は閉じます。 「オープンクローズの原則」 ファクトリ パターンは特定の製品を拡張します。プロジェクトによっては、より拡張性が必要になる場合があります。この「ファクトリ」を拡張したい場合は、「抽象ファクトリ パターン」になります。

• リヒター置換原理

リスコフ置換原理は、「Barbara Liskov」によって提案されました。親クラスを呼び出した場合は、サブクラスに変更すれば実行可能になります。例: CD d=new 海賊版ディスク(); d. sell(); 「海賊版ディスク」カテゴリを「ポルノ映画」カテゴリに変更したい場合でも、問題なく完全に実行できます。 Java コンパイラは、プログラムがリスコフ置換原則に準拠しているかどうかをチェックします。 Java 継承の原則をまだ覚えていますか?サブクラスのオーバーライド メソッドのアクセス権は、親クラスの対応するメソッドのアクセス権より低くすることはできません。たとえば、「CD」の「Sell」メソッドのアクセス許可が「public」である場合、「Pirate Disc」と「Raw Film」の「Sell」メソッドは保護または非公開にすることができず、コンパイルは通過しません。なぜこのようにしなければならないのでしょうか？ 「海賊版ディスク」の「販売」方法が非公開である場合を考えてみましょう。 CD d=new 海賊版ディスク(); d. sell(); リスコフ置換原則は継承と再利用の基礎であると言えます。

• 合成と再利用の原則

これは、継承の使用を減らし、合成関係をより多く使用する必要があることを意味します。以前、次のようなプログラムを書いたことがあります。データベースを扱う必要があるクラスがいくつかあるので、データベース操作用のクラスを作成し、データベースを扱う他のクラスがこれを継承します。その結果、後でデータベース操作クラスのメソッドを修正したところ、すべてのクラスを修正する必要がありました。 「一つの動作が全身に影響を与える」! 変動を最小限に抑えるのがオブジェクト指向です。

Java では、実装クラスではなくインターフェイス用にプログラミングするようにしてください。こうすることで、サブクラスを変更しても、そのメソッドを呼び出すコードには影響しません。各カテゴリーは「知らない人と話さない」、他のカテゴリーとの接触をできるだけ少なくしましょう。こうすることで、城門が火災になっても、池の魚に被害が及ぶことはありません。スケーラビリティと保守性を改善できるのは、

#これらの原則を理解し、設計パターンを検討した後、特定の問題に対してこれらの原則を実装する方法だけです。張無忌は太極拳を学び、すべての動きを忘れて「二老の玄奘」を破ったが、「頭には動きがなかった」と言われている。デザインパターンはトリックとも言えますが、最初にすべてのパターンを覚えてから、すべてのパターンを忘れて好きにすれば、それはOOの最高の状態と言えます。ははは、面白い、面白い！ (JR)

依存関係反転の原則の抽象化は詳細に依存すべきではなく、詳細は依存する必要があります

• 依存関係反転の原則

実装ではなくインターフェイスに対してプログラムします。パラメーターを渡すとき、または結合された集計関係で、より上位レベルのクラスを参照するようにしてください。主な理由は、オブジェクトを構築するときにさまざまな具象オブジェクトを動的に作成できるためです。もちろん、一部の具象クラスが比較的安定している場合は、抽象クラスをその親クラスとして作成する必要はありません。これは余分です。インターフェース分離原則はカスタマイズします。例: 各

• #インターフェイス分離原則

#役割は、それ以上でもそれ以下でもなく、やるべきでないことを行わないでください。抽象クラスはすべてを行う必要があります。抽象クラスにはインスタンスはありません

• 抽象クラス

クラスはサブクラスによって継承され、通常はこのシステムの共通の属性とメソッドが含まれます。注: 適切な継承関係では、リーフ ノードのみが具象クラスであり、他のノードは抽象クラスである必要があります。つまり、具象クラスは継承されません。可能な限り共通のコードを抽象クラスに配置します。 7 デメテルの最小知識の法則。見知らぬ人と話さないでください。

このデザイン パターン チュートリアル マニュアルの内容

このデザイン パターン チュートリアルでは、ファクトリ パターン、抽象ファクトリ パターン、シングルトン パターン (シングルトン パターン)、ビルダー パターン (ビルダーパターン）、プロトタイプパターン（プロトタイプパターン）など

ヒント: このチュートリアルの各章には、設計パターンをよりよく学習して理解するのに役立つ多くの Java の例が含まれています。