デザインモード - シングル責任の原則ソフトウェア設計原則2 -

シングル責任（シンプル責任Pinciple、SRP）は、クラスの変更よりも多くを起こさない理由があることを意味します。需要が変更されると、我々は、責任の二つの領域を担当するクラスがあるとし、内の論理責任コードを変更し、別の障害の機能的責任につながる可能性があります。その結果、これは変更する理由がある二つのクラスのクラスにつながります。どのようにこの問題を解決するには？我々は2つのクラスは、デカップリングを達成した2つの責務を使用しようとしています。ポストメンテナンス要件は、互いに独立して変化します。このデザインは変更に起因するリスクを低減、システムの保守性を向上させる、クラスが読みやすく、クラスの複雑さを軽減することができます。全体的に、それはクラス/インタフェース/メソッドは、義務のための唯一の責任です。 次に、我々は、コード例を見て、またはカリキュラムを使用して、例えば、私たちのコースは、ライブとクラスのレッスンをテープで固定されています。ライブクラスは早送りや巻き戻し、録画放送が任意に表示を繰り返すことができないことができ、機能的な責任は同じではありません。またはコースカテゴリを作成します。

1  パッケージcom.lch.test.simpleresponsibility;
 2  
。3  / ** 
4  *単一責任
 。5   * / 
6。 パブリック クラスコース、{
 7。     公共 ボイド研究（文字列CourseName）{
 8。         IF（ "ライブコース" .equals（CourseName））{
 図9              のSystem.out.println（CourseName + "ではなく早送り" ）;
 10          } 他{
 11              のSystem.out.println（CourseName + "繰り返し振り返ることができる" ）;
 12          }
 13      }
 14 }

1つの パッケージcom.lch.test.simpleresponsibility。
2つの 
3  パブリック クラスSimpleResponsibilityTest {
 4      パブリック 静的 ボイドメイン（文字列[]引数）{
 5          コースコース= 新しいコース（）。
6          course.study（ "直播课" ）。
7          course.study（ "录播课" ）。
8      }
 9 }

以上の観点からのコード、コースクラスは、二つの処理ロジックを取ります。場合は、今や当然の暗号化され、暗号化ロジッククラスのライブと記録のクラスが同じではありません、あなたは、コードを変更する必要があります。そして、コードのロジックが制御不能リスクにつながる簡単にお互いに影響を与えるにバインドされ変更します。我々は2つのクラスそれぞれReplayCourseとLiveCourseを作成し、コードを見て、職務分掌のデカップリング：

1つの パッケージcom.lch.test.simpleresponsibility。
2  
3  パブリック クラスLiveCourse {
 4      公共 ボイド試験（文字列courseName）{
 5          のSystem.out.println（courseName + "不能快进看" ）。
6      }
 7 }

1つの パッケージcom.lch.test.simpleresponsibility。
2  
3  パブリック クラスReplayCourse {
 4      公共 ボイド試験（文字列courseName）{
 5          のSystem.out.println（courseName + "可以反复看" ）。
6      }
 7  
8 }

電話番号

1つの パッケージcom.lch.test.simpleresponsibility。
2  
3  パブリック クラスSimpleResponsibilityTest2 {
 4      パブリック 静的 ボイドメイン（文字列[]引数）{
 5         LiveCourse liveCourse = 新しいLiveCourse（）。
6         liveCourse.study（ "直播课" ）。
7         ReplayCourse replayCourse = 新しいReplayCourse（）。
8         replayCourse.study（ "录播课" ）。
9      }
 10 }

ビジネスは、行うにはカリキュラムの権限を開発し続けています。もちろんに関する基本的な情報のために支払うことができない学生は、学生はすなわち許可を学習、ビデオストリームを取得するために支払う必要があります。そこで、制御レベルのコースのための責任の少なくとも二つの領域があります。我々は、彼らが1と同じ抽象依存している、分離責任と経営責任を表示することができます。トップレベルインターフェース設計、作成ICourseインタフェースを：

1  パッケージcom.lch.test.simpleresponsibility;
 2  
。3  パブリック インターフェイスIcourse {
 4。     // 基本情報
5。     ストリングgetCourseName（）;
 6  
。7      // 映像ストリームを取得
8      バイト[] getCourseVideo（）;
 9  
10      // 学習コース
11      無効studyCourseを（）;
 12である 
13ことである     // 払い戻し
14      ボイド）（refundCourse;
 15 }

このインタフェースは、インタフェースICourseInfoとICourseManager、ICourseInfoインタフェースを作成する、二つのインターフェースに分割することができます。

1  パッケージcom.lch.test.simpleresponsibility;
 2  
。3  パブリック インターフェイスICourseInfo {
 4。     // 基本情報
5。     ストリングgetCourseName（）;
 6  
7。     // 映像ストリームを取得
8      バイト[] getCourseVideo（）;
 9 }

1  パッケージcom.lch.test.simpleresponsibility;
 2  
。3  パブリック インターフェイスICourseManager {
 4。     // 学習コース
5。     ボイドstudyCourse（）;
 6  
。7      // 払い戻し
8。     ボイドrefundCourse（）;
 9 }

ここでは、単一の設計業務の方法のレベルを見てください。時々、私たちは怠惰でなければならない、次のように、この方法は、通常書き込まれます。

1つの プライベート ボイドmodifyUserInfo（文字列ユーザ名、列アドレス）{
 2          のuserName = "トム" 。
3つの          アドレス=「長沙」。
4      }

1   プライベート ボイド modifyUserInfo（文字列ユーザ名、列アドレス、ブール値ブール値）{
 2          であれば（BOOL）{
 3          } 他{
 4              のuserName = "トム" 。
5つの              アドレス=「長沙」。
6          }
 7      }

もちろん、modifyUserInfo上記（）メソッドは、より多くの責任を負担しなければならなかった、いずれかのユーザー名を変更し、あなたがアドレスを変更することができ、さらに、明らかに単一の責任を満たしていません。だから我々は、このメソッドは、2つに分割され、以下のように変更します。

1    プライベート ボイドmodifyUserName（文字列のuserName）{
 2          のuserName = "トム" 。
3      }
 4  
5      プライベート ボイドmodifyAddress（列アドレス）{
 6つの          アドレス= "長沙" 。
7      }

この変更の後、開発は、それらを維持するために簡単に簡単です。しかし、我々はプロジェクト、ポートフォリオ、重合スケール、これらの関係の期間レベルに依存し、実際の開発では、まだプロジェクト、技術者があるが、制御の進歩は、多くのクラスは、単一の責任を満たしていません。私たちのプロジェクトのメンテナンスの後半のために、単一の責任を維持するためのインターフェースおよび方法は、大きな助けとなるように、しかし、我々は可能な限り、コードを書くの過程にあります

デザインモード - シングル責任の原則ソフトウェア設計原則2 -

おすすめ