Java デザイン パターン - デザイン パターンの 6 つの原則

6 つの設計原則

単一責任の原則

クラス変更の理由は複数あってはならない。平たく言えば、クラスは 1 つの責任のみを担当します。

問題の原因: クラス T は、責任 P1 と責任 P2 という 2 つの異なる責任を負います。責任P1の要件の変更によりクラスTを変更する必要がある場合、元々正常に動作していた責任P2の機能が誤動作する可能性があります。

一言でまとめると: 1 つのクラスに少量のコードを入れることはできません

リヒター置換原則

1 サブクラスは親クラスの抽象メソッドを実装できますが、オーバーライドすることはできません。非抽象メソッド。

2. サブクラスは独自のメソッドを追加できます。

3. サブクラスのメソッドが親クラスのメソッドをオーバーライドする場合、メソッドの前提条件 (つまり、メソッドの仮パラメータ) は、親クラスのメソッドの入力パラメータよりも緩くなります。

4. サブクラスのメソッドが親クラスの抽象メソッドを実装する場合、メソッドの事後条件 (メソッドの戻り値) は親クラスの事後条件よりも厳しくなります。

一文の要約: 親クラスの実装されたメソッドを書き直さないようにしてください。

依存関係逆転の原則

をバイパスするために、インターフェイスやその他のメソッドを使用できます。高レベルのモジュールは、低レベルのモジュールに依存すべきではありません。抽象化に依存する必要があります。抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。

説明するための例を次に示します:

import java.util.LinkedList;  
import java.util.Queue;  
  
  
  
interface IEAT  
{  
    public void eat();//抽象吃这个动作  
}  
class EatApple implements IEAT  
{  
  
    @Override  
    public void eat()   
    {  
        //这里是吃苹果  
        System.out.print("eat a apple");  
          
    }  
}  
class EatWater implements IEAT  
{  
  
    @Override  
    public void eat() {  
        // 这里是吃水  
        System.out.print("dringk water");  
          
    }  
      
}  
public class Human  
{  
    public void dosomething(IEAT ieat)//我爱吃东西，吃什么呢，看传入什么  
    {  
        ieat.eat();  
    }  
    /* 
    public void dosomething(String food)//我爱吃东西，吃什么呢，看传入什么 
    { 
        if(food.equals("apple")) 
        { 
            //吃苹果 
        } 
        if(food.equals("water")) 
        { 
            //喝水 
        } 
    } 
    */  
    public static void main(String[] args)  
    {  
        Human human=new Human();  
        /* 
        human.dosomething("apple"); 
        human.dosomething("water"); 
         */  
        //给你吃个苹果  
        human.dosomething(new EatApple());  
        //再给你喝点水  
        human.dosomething(new EatWater());  
    }  
}

注釈は、私たちがよく使用するメソッドです。この方法は拡張には非常に不向きです。バナナやスイカを食べたい場合、dosomething に大量の判定を書かなければならないからです。書いているうちに混乱してきます。

つまり、一言で言えば、同じアクションを記述するために抽象インターフェースを使用し、そのアクションを実装する人とオブジェクトの間の結合を減らす

インターフェース分離の原則

Aクライアントは、必要のないインターフェイスに依存すべきではありません。クラスの別のクラスへの依存は、最小のインターフェイスに基づく必要があります。

問題の原因: クラス A はインターフェイス I を通じてクラス B に依存し、クラス C はインターフェイス I を通じてクラス D に依存します。インターフェイス I がクラス A とクラス B の最小インターフェイスではない場合、クラス B とクラス Dメソッドを実装する必要はありません。

一言でまとめると、魚と人間と同じように、魚には泳ぐことと鰓呼吸という 2 つの動作があり、人間には歩くことと食べることの 2 つの動作があります。これらの動作は 4 つすべてを含めてインターフェイスに記述することはできません。特に魚用と人間用の 2 つのインターフェイスに分割する必要があります。

デミットの法則

デミットの法則は、最も知られていない原理とも呼ばれ、1987年にアメリカのノースイースタン大学のイアン・ホランドによって初めて提案されました。平たく言えば、クラスが依存するクラスについての知識が少なければ少ないほど良いのです。つまり、依存クラスでは、どんなに複雑なロジックであっても、ロジックは可能な限りクラス内にカプセル化し、提供されるパブリックメソッド以外には情報が外部に漏洩しないようにする必要があります。

これは少し覚えにくいです。要約すると、父 1<-子 1、父 2<-子 2、父 1 と父 2 は、父 2 を介して子 2 にアクセスしようとし、クラス内の子 2 には直接アクセスしません。部下は気軽にそこに行けますか? リーダーの子供については、他人があなたを誘拐していると言ったら注意してください

開閉原則

これについては何も言うことはありません。既存のコードを変更して変更を加えるのではなく、ソフトウェア エンティティの動作を変更します。