七つの原則：
1：シングル責任原則：クラスは、関数のための唯一の責任があります
2：リヒター置換原則（LSP）：サブタイプは、その親タイプを置き換えることができなければなりません。
3：オープンクローズ原理：拡張機能へのオープンは、変更のため閉鎖。
4：アイソレーションインタフェース原理：クライアントが不要なインターフェースに依存してはならない、他のクラスに依存するクラスは、最小のインターフェイスに基づくべきです
5：依存関係逆転の原則：高レベルのモジュールは、その抽象的に依存している必要があり、どちらも低レベルのモジュールに依存すべきではありません。
6：ドミトリー原則：少なくともノウハウの原則
7：組み合わせ集約マルチプレクサ原則：ソフトウェアの再利用、会合または重合の組み合わせを使用して実装されるようにしようとするが、達成するための継承の使用を検討する前に続きます。
1：単一責任の原則
意味：クラスの理由を、このような変化の一つの原因があり、デューティ・クラスは、ユニークであり、この義務は変更の他の種類の唯一の原因です。
人気のポイント、クラスが1種類のことを行う必要があります。クラスは唯一の機能を担当する必要があります。
目的：コードの複雑さを軽減するために、システムを切り離すには、読みやすさを向上させます
例えば：
単語などを覚えておくべき一つの原則は、「クラスが一つの機能のための唯一の責任がある」です。たとえば、今、私たちは、達成されるべき二つの機能音楽を写真を撮るとプレイしています。この2つの機能を単一のクラスにパッケージ化されている間違ったアプローチで、正しいアプローチは、カメラ、音楽プレーヤー機能の実装を実現するために、2つのクラスをパッケージ化することです。
コードは以下の通りであります：
// 定义拍照类
class Photograph{
constructor(name){
this.name = name
}
photograph(){
console.log(`给${this.name}拍照`)
}
}
// 定义播放音乐类
class PlayMusic{
constructor(musicName) {
this.musicName = musicName
}
outMusicName(){
console.log(`播放音乐${this.musicName}`)
}
}
var photograph1 = new Photograph('小明');
var playMusic1 = new PlayMusic('爱我中华');
photograph1.photograph(); // 给小明拍照
playMusic1.outMusicName();// 播放音乐爱我中华
2：リヒター置換原則（LSP）
定義：代用すると、この原則の道徳的で、親クラスのすべてのローカル参照は、彼のために代替のサブクラスすることができます。
本当に無知の力を見たときに、この原則に新しい、親クラスをサブクラス置き換えますか？地獄！
私の理解で説明します。
この原則は、あなたがこのサブクラスの上に継承によって、この機能を確保するために、この例では、機能を実装することにより、インスタンス化インスタンスの親クラスを親クラスのインスタンスをインスタンス化することを意味し、同じことが、この機能を実現することができます。（純粋に個人的な理解、噴霧されるべきではありません）
例えば：
鳥はすでに飛行する方法を定義している、と今鳥のインスタンスをインスタンス化することによって鳥は、達成し、鳥が（関数）1を飛ぶように飛ぶメソッドを呼び出します。
ダチョウは、クラスを定義し、ワシのクラスは鳥から継承します。このような文言は、私たちのリヒターの置換原則の違反です。あなたはダチョウを置き換えるために、実施例1で使用されていないダチョウダチョウ1によるクラスのインスタンスをインスタンス化するので、決して実施例1とダチョウなど鳥類の上記の実施例1実施例による鳥は、機能を飛びます、リヒターは、機能を置き換える違反しています。
正しいアプローチは、あなたが、二つの平行な親鳥を作成飛ぶ飛ぶべきではない、飛ぶ鳥で、鳥は親クラスの飛行、飛べない鳥飛べない鳥の継承を継承します親クラス。
// 定义会飞的鸟类
class CanFly{
constructor(name){
this.name = name
}
canFly(){
console.log(`我是${this.name} I can fly`)
}
}
// 定义不会飞的鸟类
class NotCanFly{
constructor(name) {
this.name = name
}
notCanFly(){
console.log(`我是${this.name} I not can fly`)
}
}
// 定义老鹰类
class LaoYing extends CanFly{
constructor(name,color) {
super(name);
this.color = color
}
color(){
console.log(this.color)
}
}
// 定义鸵鸟类
class TuoNiao extends NotCanFly{
constructor(name,color) {
super(name);
this.color = color
}
color(){
console.log(this.color)
}
}
var laoYing1 = new LaoYing('老鹰一','白色');// 通过LaoYing类实例化老鹰1实例
var laoYing2 = new CanFly('老鹰二');// 通过会飞的鸟类实例化老鹰2实例
laoYing1.canFly()// 我是老鹰一 I can fly
laoYing2.canFly()// 我是老鹰二 I can flyこれはリヒターで、上記の例とは、アウトクラスによってイーグルス1及び2は、ワシの例ではないことがわかりますが、親クラスのうち子によってインスタンス化されますが、フライ機能を実装することができます置換原則。
3：オープンクローズ原理
方言は、我々は（そのような他の機能の拡張として）ソフトウェアを変更した場合、ソフトウェアスケーラブルな方法を変更することによって達成されるべきであり、変更を実装するために元のコードを変更してはならないことを意味します。
端的に言えば、それはこれらのエンティティは、さまざまなアクションを実行する必要があるということであることは何も変更を必要としないように設計されなければならない変化の多様性を達成することができ、コードの保守を最小限に抑えてプロジェクトを支持して開閉の原則に準拠しています。私はそれが多型の開閉の原則を反映していると思います。（個人的な理解は、噴霧すべきではありません。）
栗の場合：
// 定义大鱼类
class BigFish{
constructor(name) {
this.name = name
}
eat(){
console.log(`我是大鱼我吃小鱼`)
}
}
// 定义小鱼类继承大鱼类
class SmallFish extends BigFish{
constructor(name) {
super(name)
}
// 重写吃方法，小鱼类只能吃虾米
eat(){
console.log(`我是小鱼我吃虾米`)
}
}4：インターフェイスの棲み分け原理
意味：クライアントが不要なインターフェースに依存すべきではない、別のクラスに依存したクラスは、最小のインターフェイスに基づいている必要があります。
栗の場合：
テスト玉樹ワイ、物理学、化学、政治史や地理や他のインタフェースである上記試験インターフェイスを持つテストクラスが用意されました。芸術の学生や科学の授業の学生の授業は受験クラスを継承、インターフェース・テストを実装するクラスは、検査を実施しています。ここでは文系の学生は物理化学をテストする必要がないため、インターフェイス分離の原則のいくつかの違反は、ある、科学の学生はまた、政治史や地理をテストする必要はありません。
ソリューション：
科学の学生それぞれが、追加のテストインターフェースの芸術を実装し、生の芸術、科学のテスト・インタフェース、インタフェースの改善の検討、調査は、芸術と科学のテストインタフェースをインタフェースします。
// 文科考试接口
class ArtsExam{
constructor(name) {
this.name = name
}
exam() {
console.log(`我是${this.name}我要参加考语数外历史地理政治`)
}
}
// 理科考试接口
class ScienceExam{
constructor(name) {
this.name = name
}
exam() {
console.log(`我是${this.name}我要参加考语数外物理化学生物`)
}
}
// 文科学生
class Arts extends ArtsExam{
constructor(name){
super(name)
}
}
// 理科学生
class Science extends ScienceExam{
constructor(name){
super(name)
}
}
student1=new Arts("文科生小红")
student1.exam()// 我是文科生小红我要参加考语数外历史地理政治
student2=new Science("理科生小明")
student2.exam()// 我是理科生小明我要参加考语数外物理化学生物5：依存関係逆転の原則
キー：
高レベルのモジュールは、抽象的に依存している必要があり、どちらも低レベルのモジュールに依存してはならない
の詳細に依存するべきではありません抽象
抽象依存すべき詳細
過度の保守作業が生じ需要の変化を避けるために：目的を
説明：プログラムは、特定の実装に依存しない、抽象インタフェースに依存するだけです。抽象的プログラミングのための要件、プログラミングを実装するためではありません。
栗の場合：
読書はとてもコンテンツ書籍帳クラスを出力するための方法に依存すること、であるので、人間、ヒューマンインタフェースを読み取るために、既存の。これは、人間の高レベルのモジュールであるため、本は低レベルのモジュールで、高レベルのモジュールの人間は、低レベルのモジュール書籍カテゴリに依存依存関係逆転の原則、この時間に違反します。あなたは人間が新聞を読みたい場合は、この時点では、原稿の読み取りを行うのは非常に困難です。
ソリューション：
// 阅读类
class Reader{
constructor(content) {
this.content = content
}
// 获取内容的抽象方法
outPutContent(){
throw "Abstract methods require concrete implementation";
}
}
// 书类
class Book extends Reader{
constructor(content) {
super(content)
}
// 获取内容的抽象方法的实现
outPutContent(){
console.log(`书的内容是${this.content}`)
}
}
// 报纸类
class NewsPaper extends Reader{
constructor(content) {
super(content)
}
// 获取内容的抽象方法的实现
outPutContent(){
console.log(`报纸的内容是${this.content}`)
}
}
// 人类
class People{
constructor(name) {
this.name = name
}
// 读抽象方法的具体实现
reader(what){
console.log(`${this.name}读的`,what.outPutContent())
}
}
let xiaoMing = new People('小明')
let xiaoHong = new People('小红')
let anTuSheng = new Book('安徒生故事')
let wanBao = new NewsPaper('今日晚报')
xiaoMing.reader(anTuSheng);// 书的内容是安徒生故事 小明读的
xiaoMing.reader(wanBao);// 报纸的内容是今日晚报 小明读的
xiaoHong.reader(anTuSheng);// 书的内容是安徒生故事 小红读的
xiaoHong.reader(wanBao);// 报纸的内容是今日晚报 小红读的上記の依存関係反転原理の実装を実現しています。
6：ドミトリー原則
デメテルは、クラス、弱いカップリングの間のデカップリングの概念の実践です。ハイクラスとクラス間の結合の度合いは、クラスが変更された場合ならば、彼はクラス間の関係が変化します。これは、拡張やメンテナンスに加え、私たちが必要とするとき、遅延または需要の変化に非常に助長している、コードを書くのは難しいです。
栗の場合：
クラスの今ゲスト、ゲストはスクランブルエッグとトマトの料理を注文しました。このクラスは調理トマトは卵がする必要がスクランブル。なトマトのようにクラスのシェフをカットするには、揚げ、卵を破っ料理を完了するために、いくつかの方法を塩と、ゲストに料理。デメテルの原理はゲストがその後、ゲストに料理の始まりを調理、食べ物を注文し、ここで具体化され、ゲストがあなたがたの間に料理を調理絶対に知っておく必要があります。
// 客人类
class Guest{
constructor(name) {
this.name = name
}
// 点菜方法
orderDishes(val){
console.log(val.outPutDishes())
}
}
// 厨师类
class Chef{
// 切西红柿
cutTomatoes(){
console.log('切西红柿')
}
// 打鸡蛋
hitEgg(){
console.log('打鸡蛋')
}
// 放盐
putSalt(){
console.log('放盐')
}
// 给客人菜方法
outPutDishes(){
this.cutTomatoes();
this.hitEgg();
this.putSalt();
console.log()
return '西红柿炒鸡蛋'
}
}
let xiaoMing = new Guest('小明')
let chef1 = new Chef()
xiaoMing.orderDishes(chef1)7：原則多重重合性組成物
重合（凝集）が弱い自身 '関係、全体及び個々の関係、すなわち、HAS-関係を示し、分離可能とされている間の全部分、その場合、彼らは自分のライフサイクルを有していてもよいです。
（組成物）の合成、それは強い自身 "の関係で、彼の反映の関係も重合強いと呼ばれる重合よりも、この関係、-含まれています。これは、部品全体、部品と同じのライフサイクル全体の間の厳密な関係を反映しています。
合成多重化原理を公知の重合性組成物の多重原理、新しいオブジェクトは、新しいオブジェクトの一部となるように、アソシエーション（組み合わせ関係、重合の間の関係）によって、いくつかの既存のオブジェクトに使用されている。委任によって、新しいオブジェクト・コール代替機能の目的を達成するために、オブジェクトの既存の方法。簡単に言えば、重合/代わりの継承の組み合わせの使用を作るための方法。
栗の場合：
