Java デザインパターンの単一責任原則を実装する方法-＆＃＆チュートリアル-php.cn

Java デザインパターンの単一責任原則を実装する方法

WBOY

リリース： 2023-04-18 15:58:03

転載

1458 人が閲覧しました

単一責任原則 (単一責任原則)、SRP と呼ばれます。

定義:

クラスが変更される理由は 1 つだけであってはなりません。

クラスが変更される理由は 1 つだけである必要があります。

開発者は、インターフェイスの設計時に、ユーザー属性やユーザーの動作がインターフェイスで宣言されているなど、問題が発生することがあります。これにより、ビジネスオブジェクトとビジネスロジックが統合され、インターフェイスに 2 つの責任が発生します。インターフェイスの責任は明確ではありません。SRP の定義によれば、インターフェイスの単一責任の原則に違反します。

次は例です:

package com.loulijun.chapter1;     public interface Itutu {      //身高      void setShengao(double height);      double getShengao();      //体重      void setTizhong(double weight);      double getTizhong();      //吃饭      boolean chiFan(boolean hungry);      //上网      boolean shangWang(boolean silly);  }

ログイン後にコピー

上の例にはこの問題があります。身長と体重はビジネスオブジェクトであり、対応するメソッドが主にユーザーの属性を担当します。食事やインターネットサーフィンは対応するビジネスロジックであり、主にユーザーの行動を担当します。しかしこれでは、このインターフェースが何をするのかわからない、責任が明確でないという印象を与え、その後のメンテナンス時にさまざまな問題が発生する可能性があります。

解決策: 単一責任の原則。このインターフェイスを異なる責任を持つ 2 つのインターフェイスに分解するだけです。

ItutuBO.java: tutu (個人名の場合は Tutu) の属性を担当します

package com.loulijun.chapter1;     /**   * BO：Bussiness Object，业务对象   * 负责用户的属性   * @author Administrator   *   */ public interface ItutuBO {      //身高      void setShengao(double height);      double getShengao();      //体重      void setTizhong(double weight);      double getTizhong();  }

ログイン後にコピー

ItutuBL.java: Tutu の動作を担当します

package com.loulijun.chapter1;  /**   * BL:Business Logic,业务逻辑   * 负责用户的行为   * @author Administrator   *   */ public interface ItutuBL {      //吃饭      boolean chiFan(boolean hungry);      //上网      boolean shangWang(boolean silly);  }

ログイン後にコピー

これにより、インターフェイスの単一の責任が実現されます。次に、インターフェイスを実装するときに、2 つの異なるクラスが必要です

TutuBO.java

package com.loulijun.chapter1;     public class TutuBO implements ItutuBO {      private double height;      private double weight;      @Override     public double getShengao() {                 return height;      }         @Override     public double getTizhong() {          return weight;      }         @Override     public void setShengao(double height) {          this.height = height;      }         @Override     public void setTizhong(double weight) {          this.weight = weight;      }     }

ログイン後にコピー

TutuBL.java

package com.loulijun.chapter1;     public class TutuBL implements ItutuBL {         @Override     public boolean chiFan(boolean hungry) {          if(hungry)          {              System.out.println("去吃火锅...");              return true;          }          return false;      }         @Override     public boolean shangWang(boolean silly) {          if(silly)          {              System.out.println("好无聊啊，上会网...");              return true;          }          return false;      }     }

ログイン後にコピー

これにより、ユーザー属性がいつ必要になるかが明確になります。現時点では、ItutuBO インターフェイスを変更するだけで済みます。変更は TutuBO クラスにのみ影響し、他のクラスには影響しません。

では、単一責任原則の重要性は何でしょうか?

#クラスの複雑さを軽減し、実装される責任を明確に定義します
可読性の向上
保守性の向上
変更によるリスクを軽減し、システムの拡張性と保守性に非常に役立ちます

ただし、問題があります。単一責任の原則を使用する「責任」を分割するための明確な基準はありません責任を細かく分割しすぎると、インターフェイスと実装クラスの数が急激に増加し、コードの複雑さが増し、信頼性が低下します。。したがって、この責任を使用する場合は、特定の状況を分析する必要があります。インターフェイスは単一責任の原則を採用し、クラスの設計において可能な限り単一責任の原則を実装する必要があるという提案ですが、唯一の理由はクラスが変更されることです。

以上がJava デザインパターンの単一責任原則を実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。