単一の責任の原則：クラス、その変更を引き起こす1つの理由のみ。
単一の責任の原則が必要なのはなぜですか？
クラスにそれを変更する複数の理由がある場合、関数を変更すると、他の関数にバグが生じる可能性があるため、クラスに対して1つの責任しか持たないことが最善です。しかし、実際のアプリケーションで達成することは依然として困難であるため、この原則を遵守するために最善を尽くすことしかできません。
開発者は、ユーザーのプロパティやユーザーの動作がインターフェイスで宣言されているなど、インターフェイスを設計する際にいくつかの問題を抱える場合があります。これにより、ビジネスオブジェクトとビジネスロジックがまとめられ、インターフェイスに2つの責任があります。インターフェイスの責任は不明であり、SRPの定義によれば、インターフェイスの単一の責任の原則に違反しています。
これが例です：
パッケージcom.loulijun.chapter1; public interface itutu {// height void setshengao（二重の高さ）; double getshengao（）; //重量void sittizhong（二重重量）; double gettizhong（）; // boolean chifan（boolean gungry）を食べる; //インターネット上のboolean shangwang（boolean Silly）; }上記の例にはこの問題があります。身長と体重はビジネスオブジェクトに属し、対応する方法は主にユーザーの属性の原因です。インターネットの食事とサーフィンは、対応するビジネスロジックであり、これは主にユーザーの動作に責任があります。しかし、これにより、人々はこのインターフェイスが何をしているのかわからないという感覚を与え、責任は明確ではなく、その後のメンテナンス中にさまざまな問題も引き起こされます。
解決策：単一の責任の原則は、このインターフェイスを異なる責任を持つ2つのインターフェイスに分割します。
itutubo.java：Tutuの属性（Tutu、それが個人名の場合）の責任
パッケージcom.loulijun.chapter1; /*** bo：ビジネスオブジェクト、ビジネスオブジェクト*ユーザーの属性の責任* @author管理者**/パブリックインターフェイスitutubo {// height void setshengao（double height）; double getshengao（）; //重量void sittizhong（二重重量）; double gettizhong（）; }itutubl.java：配置を担当します
パッケージcom.loulijun.chapter1; /*** BL：ビジネスロジック、ビジネスロジック*ユーザー行動の責任* @Author Administrator**/public Interface itutubl {//食事を食べるブールチファン（boolean Hungry）; //エンターテインメントブールシャンワン（ブールシリー）; }これは、インターフェイスの単一の責任を実現します。次に、インターフェイスを実装するときに、2つの異なるクラスがあります
Tutubo.java
パッケージcom.loulijun.chapter1;パブリッククラスのTutuboはItutuboを実装しています{プライベートダブルハイト。プライベートダブルウェイト; @Override public double getShengao（）{return height; } @Override public double gettizhong（）{return weight; } @Override public void setshengao（double height）{this.height = height; } @Override public void sittizhong（double weight）{this.weight = weight; }}Tutubl.java
パッケージcom.loulijun.chapter1; Public Class Tutublはitutubl {@override public boolean chifan（boolean hungry）{if（hungry）{system.out.println（ "go to hout fot ..."）; trueを返します。 } falseを返します。 } @Override public boolean shangwang（boolean silly）{if（silly）{system.out.println（ "so boring、go to theインターネット..."）; trueを返します。 } falseを返します。 }}これはそれを明確にします。ユーザー属性を変更する必要がある場合、Tutuboクラスのみに影響を与え、他のクラスには影響しないItutuboインターフェイスを変更するだけで済みます。
要約：
1.実際の状況は、多くの場合、「変化の原因」を事前に予測できないため、経験に基づいてインターフェースのみを構築し、1つのインターフェイスに責任が1つしかないことを確認することができます。ここで話しているのはインターフェイスです。クラスは複数のインターフェイスを継承して実装して、単一の責任を達成することをより困難にします。
2。以前に書いたクラスに、変更の複数の理由があった場合、それをリファクタリングすることが最善です。
ただし、単一の責任を使用するという原則には問題があります。 「責任」に関する明確な分割基準はありません。責任が詳細に分割されている場合、インターフェイスと実装クラスの数が急激に増加し、複雑さが向上し、コードの保守性が低下します。したがって、この責任を使用する場合、特定の状況も分析する必要があります。提案は、インターフェイスが単一の責任の原則を採用し、クラスの設計で可能な限り単一の責任原則を実現する必要があることです。 1つの理由が発生した場合、クラスの変更を引き起こすのが最善です。