オブジェクト向けの設計を初めて知った--7つの原則の概要
オブジェクト向け設計には以下の原則があります.
1.開閉原則Open-Close Principle(OCP)2.Liskov Substitution Principle(LSP)3.単一職責原則Single Responsibility Principle(SRP)4.インターフェース分離の原則Interface Segregation Principle(ISP)5.逆置きの原則に依存するDependence Inversion Principle(DIP)6.ディミット原則/最低知識原則Law of Demeter or Least Knowledge Principle(LOD orLKP)7.組合せ/集約多重化の原則Component/Aggregation Reuse Principle(CARP)
概要
1.開閉原則:
注意点:
1.高集約、低結合、および単一機能の「競合」は、実際には同じことです.集約は、1つのクラスにすべての関連する方法を一緒に置くことを要求し、最初は職能が多いが、「高」があり、連絡が非常に緊密な機能を一緒に置くことを要求している.つまり、全体的に見ると、1つの職能であるから、両者は異なる表現である.
2.複数の単一機能インタフェースの柔軟性と宣言タイプの問題1つのクラスが複数のインタフェースを実現する場合、このクラスはどのインタフェースタイプで宣言すべきですか.1つの抽象クラスで複数のインタフェースを継承し、実装クラスでこの抽象クラスを継承するはずです.宣言するとき、タイプは抽象クラスです.3.最小限の知識原則と仲介類の氾濫の2つの極端な状況ディミット原則は類の中間が仲介で通信することを要求しているが、類が多くなると、仲介類の氾濫をもたらす場合があり、このような状況は、仲介モードを考慮し、1つの全体的な仲介類で実現することができる.もちろん、デザインモデルには独自の欠陥があり、ディミットの原則も完璧ではなく、インタラクティブなクラスが非常に多い場合は、デザインの原則を適切に犠牲にしなければならない.4.継承と組合せ重合多重化の原則の衝突継承も多重化を実現できるが、この原則は継承を放棄するのではないか.いいえ.継承が重視するのは「血統」、つまりどんなタイプなのか、組み合わせの集約が重視するのは「スキル」を借りることだ.また、コンビネーション集約では、2つのクラスが部分的に全体との関係であり、コンビネーション集約は複数のクラスのスキルから構成することができる.C#とJavaでは単一継承のみです.この原則は,多重化の点で組合せ重合を優先することを示している.
きょうせい問題
1.こんなにたくさんのデザインパターンを勉強して使うの?私たちは全体の原則を身につけて、それからよく使うことを勉強すればいいだけです.実際の開発では、どのデザインモデルでもよく使われるわけではありません.結局、設計モデルもアーキテクチャも、需要のためにサービスされているので、需要ビジネスモデルがなく、無理なモデルを持ち運ぶことはできません.私たちは勉強するとき、もっと勉強するのはいつもいいですが、自分の視野を広げるためだけです.2.デザインパターンは仕様ですか?良いプログラムは設計モードを使用しなければなりませんか?厳密に言えば、良いプログラムは設計モードではなく設計原則に従っている.今すぐ多くの新しい発展のモードが現れて、これらはすべて新しい業務の原因が現れたためで、設計のモードは規範ではありませんて、ただ1種の参考です.3.デザインモデルを使うと開発の難易度が高くなりますか?開発段階はでき、開発時間も延長されます.しかし、1つのプロジェクトまたは製品は最初から最後まで、開発はそのほんの一部にすぎず、メンテナンスと拡張コストを考慮して設計モデルが現れます.全体的に考えて、設計モデルは開発時間とコストを減らした.
1.開閉原則Open-Close Principle(OCP)2.Liskov Substitution Principle(LSP)3.単一職責原則Single Responsibility Principle(SRP)4.インターフェース分離の原則Interface Segregation Principle(ISP)5.逆置きの原則に依存するDependence Inversion Principle(DIP)6.ディミット原則/最低知識原則Law of Demeter or Least Knowledge Principle(LOD orLKP)7.組合せ/集約多重化の原則Component/Aggregation Reuse Principle(CARP)
概要
1.開閉原則:
： ， 。私たちが書いたコードは、需要が変化したからといって、既存のコードを修正することはできません.私たちはコードを追加することで、変化の需要を解決することができます.現実では、このような修正をできるだけ縮小しなければならない.意味:需要が変動するたびに既存のコードを修正しなければならない場合、元のコードには修正ミスのリスクがあります.もちろん、この中には意図的で無意識の修正があり、元の正常な動作の機能が失効するリスクがあります.これは蝶効果を引き起こし、メンテナンス作業を急増させる可能性があります.潜在セリフ:需要変動リスクをコントロールし、メンテナンスコストを縮小する.他の原則はすべてこの原則のために奉仕している.2.リ氏置換原則: ： 。これは多態の前提であり、我々の後の多くのいわゆる柔軟性は、宣言タイプを変更することなく、インスタンス化クラスを変更して完了する需要変更である.潜台詞:できるだけ正確な抽象類やインタフェースを使う.3.単一職責原則: ： ， 。柔軟な前提で、クラスを最小の職能単位に分割すると、その組み合わせと多重化は簡単で、一つのクラスがやることが多すぎると、組み合わせの時、不要な方法が発生し、これは汚染である.潜台詞:最小単位に分割し、多重化と組合せの問題を解決します.4.インタフェース分離の原則: ： ， 、 。それは単一の職責の必要な手段であり、サブクラスが職能単一を達成したい場合、インタフェースも職能単一を満たさなければならない.逆に、インタフェースが複数の関連のない方法を融合させると、そのサブクラスはすべての方法を実現せざるを得ないが、一部の方法はまったく使えないが、これがインタフェース汚染である.潜台詞:分割、インタフェースから.5.依存逆置きの原則: ： 。対象初期のプログラムに向けて、被呼び出し者は呼び出し者に依存し、つまり呼び出し者は被呼び出し者にどのような方法があるか、どのような実現方式があるかを決定し、このような構造は変更が必要な場合、大きな代価を払って、甚だしきに至っては再書きを覆す.依存逆置きの原則は,呼び出し者と被呼び出し者が抽象に依存することを要求し,線河陽の両者には直接的な関連や接触はなく,変動の際,一方の変動は他方の変動に影響を及ぼさない.潜在的なセリフ:抽象的なプログラミング、呼び出しと呼び出し者をデカップリングします.6.ディミットの原則: ： ， ， 。クラスが私用の方法とフィールドを露出しすぎると、呼び出し者を困惑させる.またクラスに不要な判断コードをもたらす.だから、できるだけ低いアクセス修飾子を使って、外部に私たちの内部を知られないようにするのも、オブジェクト向けの基本的な考え方です.これはディミットの原則の1つの特性で、クラスのもっと多くの私有情報を理解することができません.また,ディミット原則はクラス間の直接的なつながりをできるだけ少なくし,2つのクラスのアクセスを3番目の仲介クラスで実現することを要求している.潜せりふ:見知らぬ人と話をしないで、仲介に行くことがあります.7.コンビネーション/集約多重化の原則: ： ， ， 。が継承する結合性はより大きく、例えば親が後にインタフェースを追加して実装したり、インタフェースを削除したりすると、サブクラスは壊滅的なコンパイルエラーを受ける可能性があるが、コンビネーション集約だけでクラスを参照する方法では、このような大きなリスクはなく、多重化も実現される.潜せりふ:私はただあなたの方法を使って、私たちは必ずしも同類ではありません.注意点:
1.高集約、低結合、および単一機能の「競合」は、実際には同じことです.集約は、1つのクラスにすべての関連する方法を一緒に置くことを要求し、最初は職能が多いが、「高」があり、連絡が非常に緊密な機能を一緒に置くことを要求している.つまり、全体的に見ると、1つの職能であるから、両者は異なる表現である.
2.複数の単一機能インタフェースの柔軟性と宣言タイプの問題1つのクラスが複数のインタフェースを実現する場合、このクラスはどのインタフェースタイプで宣言すべきですか.1つの抽象クラスで複数のインタフェースを継承し、実装クラスでこの抽象クラスを継承するはずです.宣言するとき、タイプは抽象クラスです.3.最小限の知識原則と仲介類の氾濫の2つの極端な状況ディミット原則は類の中間が仲介で通信することを要求しているが、類が多くなると、仲介類の氾濫をもたらす場合があり、このような状況は、仲介モードを考慮し、1つの全体的な仲介類で実現することができる.もちろん、デザインモデルには独自の欠陥があり、ディミットの原則も完璧ではなく、インタラクティブなクラスが非常に多い場合は、デザインの原則を適切に犠牲にしなければならない.4.継承と組合せ重合多重化の原則の衝突継承も多重化を実現できるが、この原則は継承を放棄するのではないか.いいえ.継承が重視するのは「血統」、つまりどんなタイプなのか、組み合わせの集約が重視するのは「スキル」を借りることだ.また、コンビネーション集約では、2つのクラスが部分的に全体との関係であり、コンビネーション集約は複数のクラスのスキルから構成することができる.C#とJavaでは単一継承のみです.この原則は,多重化の点で組合せ重合を優先することを示している.
きょうせい問題
1.こんなにたくさんのデザインパターンを勉強して使うの?私たちは全体の原則を身につけて、それからよく使うことを勉強すればいいだけです.実際の開発では、どのデザインモデルでもよく使われるわけではありません.結局、設計モデルもアーキテクチャも、需要のためにサービスされているので、需要ビジネスモデルがなく、無理なモデルを持ち運ぶことはできません.私たちは勉強するとき、もっと勉強するのはいつもいいですが、自分の視野を広げるためだけです.2.デザインパターンは仕様ですか?良いプログラムは設計モードを使用しなければなりませんか?厳密に言えば、良いプログラムは設計モードではなく設計原則に従っている.今すぐ多くの新しい発展のモードが現れて、これらはすべて新しい業務の原因が現れたためで、設計のモードは規範ではありませんて、ただ1種の参考です.3.デザインモデルを使うと開発の難易度が高くなりますか?開発段階はでき、開発時間も延長されます.しかし、1つのプロジェクトまたは製品は最初から最後まで、開発はそのほんの一部にすぎず、メンテナンスと拡張コストを考慮して設計モデルが現れます.全体的に考えて、設計モデルは開発時間とコストを減らした.