分類、デザインパターン
全体的に、三つのカテゴリーにデザインパターン：
Factory Methodパターン、Abstract Factoryパターン、シングルトン、Builderパターン、プロトタイプモデル：スキーマ、5つのカテゴリーの合計を作成します。
構造モデル、7種類の合計：アダプタモード、装飾的なモード、プロキシモード、外観モード、ブリッジモード、組み合わせモード、フライ級。
行動パターン、11種類の合計：Strategyパターン、モードを説明するためのテンプレートメソッドパターン、オブザーバーモード、イテレータパターン、責任のチェーン・モード、コマンドモード、メモモード状態モード、ビジターパターン、仲介モデル。
並行処理パターンとスレッドプールモード：実際には、2つのタイプがあります。
第二に、のデザインパターン6つの原則
-
単一責任の原則
-
リヒター置換原則
-
依存関係逆転の原則
-
インターフェイスの棲み分け原理
-
ドミトリー原則
-
オープンクローズ原理
シングル責任
-
コンセプト：機能的分類、コードのデカップリング
-
栗：ネットワーク要求フレームは大別される：要求クラス、キャッシュ、構成、および、これらの3つの機能を一緒に混合することができない、3つのカテゴリに分類されなければならないが、異なる機能を達成するためであります
リヒターの交換
-
コンセプト：クラスを継承すると、新機能の一部の拡大に加えて、親クラスのメソッドへの参照を削除または変更しないようにしよう、だけでなく、親クラスのメソッドをオーバーロードしないようにしようと、
-
栗は：サブクラスがこのメソッドとリターンヌルをオーバーライドする場合は、各クラスは、オブジェクトのサブクラスである、オブジェクト・クラスは、toString（）メソッドを有し、ヌルは、このレベルの継承サブクラスに戻され、その後別の開発者がこの問題のメンテナンスを考慮し、クラッシュにプログラムを引き起こす可能性があるかもしれません
依存関係反転
-
コンセプト：高レベルのモジュールは、低レベルのモジュールの詳細に依存しない高レベルの詳細に依存しないのではなく、抽象（特定のカテゴリに依存しないのではなく、インターフェイスに依存している）に依存しています
-
栗：効率的OkHttpフレームワークを使用することができますさまざまな開発者のニーズを満たすためにネットワークのフレームワーク、あなたはネイティブAPIを使用することができます。いわゆるカブキャベツがされているすべてのそれを切り替えることがいかに愛、インターフェースのアイデアを指向プログラミングの必要性のこの時期、及び一つのインタフェースにパッケージ化、いくつかのネットワーク要求の方法を持っているし、次にインタフェースの実装クラスOkHttpとネイティブAPIを作成し、もちろん、他のネットワークのフレームワークのアプリケーションを拡張するためにフォローアップ他の開発者に容易に
インターフェイスの棲み分け
-
概念：シンプルの追求可能な限り最小限に、合理化されなければならないインターフェイスメソッドを定義するときに、肥大化したインターフェースを避けます
-
栗：実際の開発では、多くの場合、時間を節約するために、おそらくより実際には、この概念が正しくないと、インタフェースのメソッド関数に描画されます、それはインターフェースになり肥大化した状態であり、あなたは、合理的な分割を必要としますメソッドインタフェース、肥大化を理解するのに困難な原因レガシーインターフェースコードを避けるために別のインタフェースへの追加の抽出
ディミトリス|最低ノウハウ
-
コンセプト：オブジェクトが他のオブジェクトに理解以上である必要があります。このクラスは、発信者または依存に関連しているか複雑な内部クラスの実装では、問題ではないか、彼らのニーズの少なくともが結合またはコールカテゴリ発信者または扶養家族を知っている必要があります彼は必要な方法を知って、他のないようにする必要がありますし、気にしないだろうだけ。近いクラスとクラスの間の関係、より大きなクラスが変更された場合、結合の程度は、別のクラスの影響も大きいです。友人とのみ直接通信。各オブジェクトが他のオブジェクトとの結合関係を有するように結合され、2つのオブジェクト間の結合は、このような組み合わせ、重合依存性などの多くの種類があり、友人関係、この関係になります。
-
栗：フレームワークを使用する場合のような仲介者としての主要なクラスは、単に他のクラスのフレームワーク内部、フレームワーク内の他のクラスを呼び出すようにしながら、一般的に、フレームワークの開発者は、外部コールのクラスをとっているであろうが（一般的にアクセスできないコール）、およびこのフレームワークは、デメテルの原則を遵守します、他の開発者が唯一のメソッド呼び出しを気に、あなたは、特定の機能を実装する方法を心配する必要はありません
開閉
-
コンセプト：クラス、モジュールおよび機能拡張のために開いている必要があり、修正のため閉鎖
-
栗：変更、アップグレード、および保守またはその他の理由は、既存のソフトウェア・コードを変更する必要があるのため、ソフトウェアのライフサイクルでは、古いコードがエラーを導入している可能性や、私たちは全体の機能を再構築する必要がありますする可能性があり、かつ私たちは、オープンすると密接原則的にこの問題を解決するために必要で、開発サイクルに大きな影響、この時、元のコードが再テストされています全体のプロセスを必要とします
概要
-
シングル責任原則は、単一のクラスの責任を実装することを教えてくれる
-
リヒター置換原理は継承階層を破壊しないように教えてくれる
-
依存関係逆転の原則は、インターフェイス指向プログラミングすることを教えてくれる
-
インターフェイスの棲み分け原理は、単一の合理化するために、時間のインターフェースの設計に教えてくれる
-
ディミトリス原理は、結合を低減するために教えてくれる
-
開閉原理はマスターで、変更のため閉鎖、内線に開くことを教えて
著者：Androidの車輪の弟の
リンクします。https：//www.jianshu.com/p/068b2d0ce4e6