ソフトウェアを書くのプロセスでは、私たちのプログラマは、より良いプログラムに結合し、凝集や保守性、様々な課題のスケーラビリティ、再利用性、柔軟性、およびデザインパターンから直面します
1、コードの再利用：同じ機能コードは、何度も書いていません
2、可読性：プログラミング仕様、読書や他のプログラマの理解のしやすさ
3、スケーラビリティ：あなたは新しい機能を追加する必要があり、非常に便利---メンテナンス性
4.信頼性：我々は機能を追加すると、元の関数には影響しません
5ので、プログラムは、高い凝集性を示すことが、低い結合
、実際には、プログラミングでプログラマーの原理に基づいているデザインパターンの原理が観察されなければならない、そしてそれは、様々なデザインパターンのパターンに基づいて設計されています。
PS：「多くの場合、自分の空き時間に、他の人とのギャップを広げます。」
まず、デザインパターンの7つの原則
①単一責任の原則
②インタフェースの棲み分け原理
③依存関係逆転の原則
④リヒター置換原則
⑤オープンクローズ原理
⑥デメテル
⑦合成多重化の原則
第二に、単一責任の原則
基本的な導入：クラスは唯一の義務に責任を負わなければならないクラスのため。責任、責務2：二つの異なる責任のクラスA料など。業務1 Aにおける需要の変化及び変更が、2実行エラーの職務をもたらすことができる場合、それはサイズクラスA、A1、A2に分解する必要があります。
テスト・シナリオ：車両クラス
図1に示すように、テストプログラム
分析：
①シングル責任原則の明白な違反は（クラスは唯一の任務を担当する必要があります）
車両ベースの分解スキーム2②-----
2.オプションIIテスト
分析：
①シングル責任原則に準拠（クラスのみ義務を担当する必要があります）
②、このような大きな変化は、分解の種類は、クライアントを変更しながら、
③改善：直接、スキーム3における比較的小さな変化を車両のクラスを修正-----
3.オプションIII試験
分析：
①単にメソッドを追加し、このメソッドは元のクラスが大きく変更されることはありません変更
②単一のクラスのレベルで責任の原則を遵守し、ノーありますがが、メソッドレベルで、まだ単一責任の原則であるが、
4、単一責任原則の概要
（1）クラスの複雑さを低減するには、クラスは、デューティのための唯一の原因であります
（2）は、読みやすさのクラス、メンテナンス性を向上させます
（3）変更のリスクを軽減