단일 책임 원칙 : 클래스, 변화를 일으키는 한 가지 이유입니다.
단일 책임 원칙이 필요한 이유는 무엇입니까?
클래스에 수정해야 할 여러 가지 이유가 있으면 함수를 수정하면 다른 함수에 버그가 발생할 수 있으므로 클래스에 대해 하나의 책임 만있는 것이 가장 좋습니다. 그러나 실제 응용 분야에서 달성하기는 여전히 어렵 기 때문에이 원칙을 준수하기 위해 최선을 다할 수 있습니다.
때로는 개발자가 인터페이스에서 선언되는 사용자의 속성 및 사용자 동작과 같은 인터페이스를 설계 할 때 몇 가지 문제가 발생합니다. 이로 인해 비즈니스 객체 및 비즈니스 논리가 정리되어 인터페이스가 두 가지 책임이 있습니다. 인터페이스 책임은 불분명하며 SRP의 정의에 따르면 인터페이스의 단일 책임의 원칙을 위반합니다.
예는 다음과 같습니다.
패키지 com.loulijun.Chapter1; 공개 인터페이스 itutu {// 높이 무효 SetShengao (이중 높이); 이중 getshengao (); // 무게 void settizhong (이중 무게); 이중 getTizhong (); // 부울 Chifan (부울 배고픈); // 인터넷에서 부울 샹완 (부울 바보); }위의 예에는이 문제가 있습니다. 높이와 무게는 비즈니스 객체에 속하며 해당 방법은 주로 사용자의 속성을 담당합니다. 인터넷을 먹고 서핑하는 것은 주로 사용자의 행동을 담당하는 해당 비즈니스 논리입니다. 그러나 이것은 사람들 에게이 인터페이스가 무엇을하는지 모르고, 책임은 명확하지 않으며, 나중에 유지 보수 중에 다양한 문제가 발생한다는 느낌을 줄 것입니다.
솔루션 : 단일 책임의 원칙은이 인터페이스를 다른 책임을 가진 두 인터페이스로 나눕니다.
itutubo.java : Tutu의 속성에 대한 책임 (Tutu, 개인 이름 인 경우)
패키지 com.loulijun.Chapter1; /*** BO : 비즈니스 객체, 비즈니스 객체* 사용자의 속성을 담당합니다* @Author Administrator**/public interface itutubo {// height void setshengao (이중 높이); 이중 getshengao (); // 무게 void settizhong (이중 무게); 이중 getTizhong (); }itutubl.java : 배치 담당자
패키지 com.loulijun.Chapter1; /*** BL : 비즈니스 로직, 비즈니스 로직* 사용자 행동에 대한 책임* @Author Administrator*/public interface ituBubl {// 식사 부울 Chifan (부울 굶주린); // 엔터테인먼트 부울 상성 (부울 바보); }이것은 인터페이스의 단일 책임을 실현합니다. 그런 다음 인터페이스를 구현할 때는 두 가지 클래스가 있습니다.
Tutubo.java
패키지 com.loulijun.Chapter1; 공개 클래스 Tutubo는 Itutubo {Private Double Height; 개인 이중 중량; @override public double getshengao () {반환 높이; } @override public double getTizhong () {return weight; } @override public void setshengao (이중 높이) {this.height = 높이; } @override public void settizhong (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 ( "뜨거운 냄비를 가러 가라 ...")을 구현합니다. 진실을 반환하십시오. } false를 반환합니다. } @override public boolean shangwang (부울 바보) {if (silly) {system.out.println ( "너무 지루함, 인터넷으로 이동 ..."); 진실을 반환하십시오. } false를 반환합니다. }}이것은 그것을 명확하게 만듭니다. 사용자 속성을 수정 해야하는 경우 Itutubo 인터페이스 만 수정하면 Tutubo 클래스에만 영향을 미치고 다른 클래스에 영향을 미치지 않습니다.
요약 :
1. 실제 상황은 여러 번 우리가 "변화의 원인"을 미리 예측할 수 없으므로 경험을 바탕으로 인터페이스를 구성하고 하나의 인터페이스에 하나의 책임 만 갖도록하려고 노력할 수 있다는 것입니다. 우리가 여기서 말하는 것은 인터페이스입니다. 클래스는 여러 인터페이스를 상속하고 구현하여 단일 책임을 달성하기가 더 어려워 질 수 있습니다.
2. 이전에 쓴 수업이 변경에 대한 여러 가지 이유가 있었을 때, 그것을 리팩터링하는 것이 가장 좋습니다.
그러나 단일 책임을 사용하는 원칙에는 문제가 있습니다. "책임"에 대한 명확한 분할 표준은 없습니다. 책임이 너무 상세하게 나뉘어지면 인터페이스 수와 구현 클래스의 수가 급격히 증가하여 복잡성을 증가시키고 코드의 유지 관리 가능성을 줄입니다. 따라서이 책임을 사용할 때는 특정 상황을 분석해야합니다. 제안은 인터페이스가 단일 책임 원칙을 채택하고 클래스 설계에서 가능한 한 단일 책임 원칙을 실현해야한다는 것입니다. 한 가지 이유가 발생하면 클래스를 변경하는 것이 가장 좋습니다.