단일 책임 원칙을 사용할 때 "책임"은 무엇입니까?

"단일 책임 원칙"이 "한 가지 일만"을 의미하는 것은 아님이 분명합니다. 그것이 방법에 대한 것입니다.

public Interface CustomerCRUD
{
    public void Create(Customer customer);
    public Customer Read(int CustomerID);
    public void Update(Customer customer);
    public void Delete(int CustomerID);
}

밥 마틴은 "수업은 변화해야 할 단 하나의 이유가 있어야한다"고 말했다. 그러나 SOLID를 처음 사용하는 프로그래머라면 마음을 감싸기가 어렵습니다.

나는 또 다른 질문에 대한 답변을 썼는데 , 여기서 책임은 직책과 같다고 제안했고 식당 요를 사용하여 내 요점을 설명함으로써 주제를 중심으로 춤을 추었습니다. 그러나 이것은 여전히 ​​누군가가 자신의 수업 책임을 정의하는 데 사용할 수있는 일련의 원칙을 분명히 보여주지는 않습니다.

어떻게합니까? 각 학급의 책임을 어떻게 결정하고 SRP와 관련하여 책임을 어떻게 정의합니까?

이 문제를 해결하는 한 가지 방법은 향후 프로젝트의 잠재적 요구 사항 변화를 상상하고이를 실현하기 위해 무엇을해야하는지 자문하는 것입니다.

예를 들면 다음과 같습니다.

새로운 사업 요건 : 캘리포니아에 위치한 사용자는 특별 할인을받습니다.

"좋은"변화의 예 : 할인을 계산하는 클래스에서 코드를 수정해야합니다.

잘못된 변경의 예 : User 클래스에서 코드를 수정해야하며 그 변경은 할인과 관련이없는 클래스 (예 : 등록, 열거 및 관리)를 포함하여 User 클래스를 사용하는 다른 클래스에 계단식으로 영향을 미칩니다.

또는:

새로운 비 기능적 요구 사항 : SQL Server 대신 Oracle을 사용하기 시작합니다

올바른 변경 예 : DTO에서 데이터를 유지하는 방법을 결정하는 데이터 액세스 계층에서 단일 클래스를 수정하기 만하면됩니다.

나쁜 변경 : 모든 비즈니스 계층 클래스에는 SQL Server 관련 논리가 포함되어 있으므로 모든 비즈니스 계층 클래스를 수정해야합니다.

아이디어는 향후 잠재적 변경의 풋 프린트를 최소화하여 코드 수정을 변경 영역 당 하나의 코드 영역으로 제한하는 것입니다.

최소한 수업에서 논리적 관심사와 물리적 관심사를 분리해야합니다. 예제의 큰 세트는에서 찾을 수 있습니다 System.IO네임 스페이스 : 거기에 우리가 물리적 스트림 (예를 들면의 각종 찾을 수 있습니다 FileStream, MemoryStream또는 NetworkStream) 여러 독자와 작가 ( BinaryWriter, TextWriter논리적 수준에서) 그 일을. 그들에게이 방법을 분리함으로써, 우리는 combinatoric 폭발을 방지 : 대신 필요한의 FileStreamTextWriter, FileStreamBinaryWriter, NetworkStreamTextWriter, NetworkStreamBinaryWriter, MemoryStreamTextWriter, 그리고 MemoryStreamBinaryWriter, 당신은 단지 작가와 스트림를 연결하고 당신이 원하는 것을 할 수 있습니다. 그런 다음 나중에 XmlWriter메모리, 파일 및 네트워크에 대해 별도로 다시 구현할 필요없이을 추가 할 수 있습니다 .

실제로, 책임은 변화 할 가능성이 있는 것들에 의해 좌우됩니다 . 따라서 불행히도 책임을 구성하는 요소에 도달하는 과학적 또는 공식적인 방법은 없습니다. 판결 요청입니다.

경험상 어떤 변화가 있을지에 관한 것 입니다.

우리는이 원칙의 언어를 쌍곡적이고 문자 적이며 열성적인 분노로 적용하는 경향이 있습니다. 우리는 클래스 가 변경되거나 단순히 문제를 해결하는 데 도움이되는 라인을 따라 나누는 경향 이 있습니다. (후자의 이유는 본질적으로 나쁘지 않습니다.) 그러나 SRP는 자체적으로 존재하지 않습니다. 유지 관리 가능한 소프트웨어 를 만드는 데 사용됩니다.

다시 말하지만, 부서가 변경 가능성 에 의해 주도 되지 않으면 YAGNI가 더 적용 가능하다면 실제로 SRP ¹ 에 서비스를 제공 하지 않습니다 . 둘 다 동일한 궁극적 목표를 제공합니다. 그리고 모두가 희망 - 판단의 문제이다 노련한 판단.

밥 아저씨가 이것에 대해 글을 쓸 때, 우리는 "변화를 요구하는 사람"이라는 관점에서 "책임"을 생각할 것을 제안합니다. 다시 말해서, 우리는 B 당이 변화를 요청했기 때문에 A 당이 일자리를 잃는 것을 원하지 않습니다.

소프트웨어 모듈을 작성할 때 변경이 요청 될 때 이러한 변경이 단일 개인 또는 좁은 정의 된 단일 비즈니스 기능을 나타내는 하나의 밀접하게 연결된 단일 사용자 그룹에서만 발생할 수 있는지 확인하려고합니다. 모듈을 조직 전체의 복잡성으로부터 분리하고 각 모듈이 하나의 비즈니스 기능의 요구에 책임을 지도록 시스템을 설계하려고합니다. ( 삼촌 삼촌-단일 책임 원칙 )

경험이 풍부하고 숙련 된 개발자라면 변경 될 가능성이 있습니다. 그리고 그 정신 목록은 산업과 조직에 따라 다소 다를 것입니다.

특정 응용 프로그램, 특정 조직의 책임은 궁극적으로 노련한 판단 의 문제입니다 . 변화 가능성에 관한 것입니다. 그리고 어떤 의미에서, 누가 모듈의 내부 로직 을 소유하고 있는지 에 관한 것 입니다 .

^{1. 분명히, 그것이 그들이 나쁜 분열 이라는 것을 의미하지는 않습니다 . 코드 가독성을 극적으로 향상시키는 훌륭한 부서 가 될 수 있습니다 . 그것은 단지 그들이 SRP에 의해 주도되지 않는다는 것을 의미합니다.}

"수업 변경해야 할 이유는 한 가지만 있어야합니다"를 따릅니다.

저에게 이것은 제품 소유자가 생각해 볼 수있는 무질서한 계획 ( "모바일을 지원해야합니다!", "우리는 클라우드로 가야합니다!", "중국어를 지원해야합니다!")을 의미합니다. 좋은 디자인은 이러한 계획의 영향을 더 작은 영역으로 제한하고 상대적으로 쉽게 달성 할 수 있습니다. 잘못된 디자인은 많은 코드를 작성하고 위험한 변경을 많이한다는 것을 의미합니다.

경험은 그 미친 계획의 가능성을 적절하게 평가할 수있는 유일한 방법입니다. 하나를 쉽게 만들면 다른 두 사람이 더 어려워 질 수 있고 디자인의 우수성을 평가할 수 있기 때문입니다. 숙련 된 프로그래머는 코드를 변경하기 위해 무엇을해야하는지, 엉덩이에 물릴 때 무엇을해야하는지, 어떤 트릭으로 인해 일이 쉬워 지는지 상상할 수 있습니다. 숙련 된 프로그래머는 제품 소유자가 미쳤던 물건을 요청할 때 자신이 얼마나 망가 졌는지에 대해 좋은 생각을 가지고 있습니다.

실제로 단위 테스트가 도움이된다는 것을 알게되었습니다. 코드가 융통성이 없으면 테스트하기가 어렵습니다. 모형 또는 다른 테스트 데이터를 주입 할 수없는 경우 해당 SupportChinese코드 를 주입하지 못할 수 있습니다.

또 다른 기준은 엘리베이터 피치입니다. 전통적인 엘리베이터 피치는 "만약 당신이 투자자와 함께 엘리베이터에 있었다면, 아이디어로 팔 수 있습니까?" 스타트 업은 자신이 무엇을하고 있는지, 초점이 무엇인지에 대한 간단하고 간단한 설명이 필요합니다. 마찬가지로, 클래스 (및 기능)가 무엇인지 간단한 설명이 있어야 할을 . "이 클래스는 이러한 특정 시나리오에서 사용할 수 있도록 일부 fubar를 구현합니다". 다른 개발자에게 "이 클래스는 사용자를 만듭니다"라고 말할 수 있습니다. 다른 개발자와 의사 소통 할 수 없다면 버그 가 생길 것 입니다.

아무도 모른다. 또는 적어도 하나의 정의에 동의 할 수 없습니다. 이것이 SPR (및 기타 SOLID 원칙)을 논란의 여지가있는 이유입니다.

나는 책임이 무엇인지 아닌지를 알아낼 수 있다고 소프트웨어 개발자가 자신의 경력을 통해 배우는 기술 중 하나입니다. 더 많은 코드를 작성하고 검토할수록 무언가가 단일 책임인지 다중 책임인지 판단해야합니다. 또는 코드의 개별 부분에 단일 책임이 적용되는 경우.

나는 SRP의 주요 목적이 엄격한 규칙이 아니라고 주장한다. 코드에서 응집력을 염두에두고 항상 어떤 코드가 응집성인지 아닌지를 결정하기 위해 의식적인 노력을 기울여야한다는 점을 상기시켜야합니다.

"책임"이라는 용어는 소프트웨어를 사용하여 소프트웨어가 얼마나 잘 구성되어 있는지 조사 할 수 있기 때문에 은유로 유용하다고 생각합니다. 특히 두 가지 원칙에 중점을 두었습니다.

• 책임은 권위와 비례합니다.
• 두 개체가 같은 일을 책임지지 않아야합니다.

이 두 가지 원칙은 우리가 서로 경쟁하기 때문에 의미있게 책임을지게합니다. 코드를 통해 무언가를 할 수있는 권한을 부여하는 경우 코드의 기능에 대한 책임이 있어야합니다. 이로 인해 클래스가 커져야 할 책임이 생겨서 "변화해야 할 한 가지 이유"가 더 넓고 넓은 범위로 확대되었습니다. 그러나 사물을 넓히면 자연스럽게 여러 엔터티가 같은 일을 담당하는 상황에 처하게됩니다. 이것은 실제 책임에 문제가 있기 때문에 코딩에도 문제가 있습니다. 결과적으로이 원칙은 책임을 복제되지 않은 소포로 세분 할 때 범위가 좁아지게합니다.

이 두 가지 외에도 세 번째 원칙은 합리적입니다.

• 책임을 위임 할 수 있습니다

갓 짜여진 프로그램, 빈 슬레이트를 생각해보십시오. 처음에는 하나의 엔터티 만 있으며 이는 전체 프로그램입니다. 모든 책임은 ... 당연히 어느 시점에서 기능이나 수업에 책임을 위임하기 시작합니다. 이 시점에서 처음 두 규칙은 그 책임의 균형을 강요합니다. 최고 수준의 프로그램은 관리자가 팀의 생산성을 담당하는 것처럼 전체 결과에 대해 여전히 책임이 있지만 각 하위 조직은 책임을 위임 받았으며 해당 책임을 수행 할 권한이 있습니다.

또한 보너스로 인해 SOLID는 기업 소프트웨어 개발과 특히 호환 될 수 있습니다. 지구상의 모든 회사는 책임을 위임하는 방법에 대한 개념을 가지고 있으며 모두 동의하지는 않습니다. 회사 자체의 위임을 연상시키는 방식으로 소프트웨어 내에서 책임을 위임하면 미래의 개발자가이 회사에서 업무를 수행하는 방법을보다 쉽게 ​​익힐 수 있습니다.

에서 이 회의 예일, 삼촌 밥 이주는 재미 예 :

그는 Employee변경해야 할 세 가지 이유, 변경 요구 사항의 세 가지 소스가 있으며,이 유머러스하고 뺨을 내밀지 만 설명 은 한다고 설명합니다.

• 는 IF CalcPay()방법에 오류가 및 US $의 회사 수백만 비용, CFO가 당신을 해고 할 것이다 .

• 는 IF ReportHours()방법에 오류가 및 US $의 회사 수백만 비용, 운영 책임자 (COO) 당신을 해고 할 것이다 .

• 는 IF WriteEmmployee() 방법은 많은 양의 데이터의 삭제가 발생하고 US $의 회사 수백만 비용에 오류가, CTO 인 당신을 해고 할 것이다 .

따라서 같은 클래스에서 비용이 많이 드는 오류로 인해 세 가지 C 레벨 exec가 발생할 수 있으므로 클래스에 너무 많은 책임이 있습니다.

그는 SRP 위반을 해결하는이 솔루션을 제공하지만 비디오에는 표시되지 않은 DIP 위반을 해결해야합니다.

"변경 사유"보다 사물을 세분화하는 더 좋은 방법은 두 가지 (또는 그 이상)의 행동을 수행해야하는 코드가 별도의 객체 참조를 보유해야하는지 여부를 고려하는 것에서 시작하는 것입니다. 각 작업에 대해, 그리고 하나의 작업 만 수행 할 수 있지만 다른 작업은 수행 할 수없는 공용 개체를 갖는 것이 유용한 지 여부

두 질문 모두에 대한 답이 예라면, 조치는 별도의 수업으로 수행되어야 함을 나타냅니다. 두 질문 모두에 대한 대답이 '아니오'라면, 공공 입장에서 볼 때 하나의 수업이 있어야 함을 시사합니다. 코드가 다루기 어려울 경우 내부적으로 개인 클래스로 세분 될 수 있습니다. 첫 번째 질문에 대한 답이 '아니오',하지만 두 번째 예라면, 각 작업에 대한 별도의 클래스가 있어야한다 플러스 다른 사람의 인스턴스에 대한 참조를 포함하는 복합 클래스입니다.

금전 등록기의 키패드, 신호음, 숫자 판독, 영수증 프린터 및 금전함에 대한 별도의 클래스가 있고 완전한 금전 등록기에 대한 복합 클래스가없는 경우 트랜잭션을 처리해야하는 코드가 실수로 호출 될 수 있습니다. 한 컴퓨터의 키패드에서 입력을 받고, 두 번째 컴퓨터의 신호음에서 소음을 발생시키고, 세 번째 컴퓨터의 디스플레이에 숫자를 표시하고, 네 번째 컴퓨터의 프린터에 영수증을 인쇄하며, 다섯 번째 컴퓨터의 금전 함을 띄웁니다. 각 하위 함수는 별도의 클래스에서 유용하게 처리 될 수 있지만 결합하는 복합 클래스도 있어야합니다. 복합 클래스는 가능한 많은 논리를 구성 클래스에 위임해야합니다.

각 클래스의 "책임"은 실제 논리를 통합하거나 그렇게하는 다른 여러 클래스에 공통된 연결 지점을 제공하는 것이라고 말할 수 있지만, 가장 중요한 것은 클라이언트 코드가 클래스를 보는 방법에 가장 중점을 두는 것입니다. 클라이언트 코드가 무언가를 단일 객체로 보는 것이 합리적이라면 클라이언트 코드는이를 단일 객체로 간주해야합니다.

SRP는 제대로 이해하기 어렵습니다. 코드에 '작업'을 할당하고 각 부분에 명확한 책임이 있는지 확인해야합니다. 실제 생활에서와 같이 어떤 경우에는 사람들 사이에서 일을 나누는 것이 매우 자연 스러울 수 있지만, 다른 경우에는 특히 자신이 알지 못하는 경우 (또는 그 일) 정말 까다로울 수 있습니다.

항상 먼저 작동하는 간단한 코드를 작성한 다음 약간 리팩터링하는 것이 좋습니다 . 잠시 후 코드가 자연스럽게 클러스터링되는 방식을 보는 경향이 있습니다. 코드 (또는 사람)와 수행 할 작업을 알기 전에 책임을지는 것은 실수라고 생각합니다.

모듈이 너무 많은 작업을 시작하여 디버그 / 유지하기 어려운 경우가 있습니다. 이것이 리팩토링의 순간입니다. 핵심 작업은 무엇이며 다른 모듈에 어떤 작업을 제공 할 수 있습니까? 예를 들어 보안 검사 및 기타 작업을 처리해야합니까, 아니면 먼저 다른 곳에서 보안 검사를 수행해야합니까, 아니면 코드가 더 복잡해 집니까?

너무 많은 간접 지시를 사용하면 다시 엉망이됩니다 ... 다른 원칙과 마찬가지로이 원칙은 KISS, YAGNI 등과 같은 다른 원칙과 충돌 할 것입니다. 모든 것이 균형의 문제입니다.

"단일 책임 원칙"은 혼란스러운 이름 일 것입니다. "변경해야하는 한 가지 이유"만이 원칙을 더 잘 설명하지만 여전히 이해하기 쉽습니다. 우리는 런타임에 객체가 상태를 변경시키는 원인에 대해 이야기하지 않습니다. 앞으로 개발자가 코드를 변경해야하는 원인에 대해 논의하고 있습니다.

버그를 수정하지 않는 한 변경 사항은 새로운 비즈니스 요구 사항 또는 변경된 비즈니스 요구 사항으로 인한 것입니다. 코드 외부에서 생각해야하고 외부 요인으로 인해 요구 사항이 독립적 으로 변경되는 원인을 상상해야 합니다. 말하다:

• 정치적 결정으로 인해 세율이 변경됩니다.
• 마케팅은 모든 제품의 이름을 변경하기로 결정
• UI를 액세스 할 수 있도록 다시 디자인해야합니다
• 데이터베이스가 혼잡하므로 최적화를 수행해야합니다.
• 모바일 앱을 수용해야합니다
• 등등...

이상적으로는 독립적 인 요소가 다른 클래스에 영향을 미치기를 원합니다. 예를 들어 세금은 제품 이름과 관계없이 변경되므로 동일한 클래스에 영향을 미치지 않아야합니다. 그렇지 않으면 세금 변경으로 인해 제품 이름 지정 오류가 발생할 수 있습니다. 이는 모듈 식 시스템으로 피하고 싶은 타이트한 커플 링입니다.

그러니 그냥 변경할 수 있는지의 초점하지 않습니다 - 아무것도 생각할 향후 변경 될 수 있습니다. 독립적으로 변할 수있는 것에 집중 하십시오. 변경 사항은 다른 행위자에 의해 발생하는 경우 일반적으로 독립적입니다.

직책을 가진 당신의 예는 올바른 길을 가고 있지만, 당신은 더 문자 그대로 받아 들여야합니다! 마케팅이 코드를 변경하고 재무가 다른 변경을 야기 할 수있는 경우, 이러한 변경은 문자 그대로 다른 직책이므로 변경이 독립적으로 발생하기 때문에 동일한 코드에 영향을 미치지 않아야합니다.

이 용어를 발명 한 Bob 아저씨를 인용 하면 :

소프트웨어 모듈을 작성할 때 변경이 요청 될 때 이러한 변경이 단일 개인 또는 좁은 정의 된 단일 비즈니스 기능을 나타내는 하나의 밀접하게 연결된 단일 사용자 그룹에서만 발생할 수 있는지 확인하려고합니다. 모듈을 조직 전체의 복잡성으로부터 분리하고 각 모듈이 하나의 비즈니스 기능의 요구에 책임을 지도록 시스템을 설계하려고합니다.

요약하자면 : "책임"은 단일 비즈니스 기능을 제공합니다. 두 명 이상의 배우가 수업을 변경해야 할 경우 수업에서이 원칙을 어기 게됩니다.

SOLID 프로그래밍 원칙을 설명하고이 원칙을 따르거나 따르지 않는 코드 예제를 제공하는 좋은 기사는 https://scotch.io/bar-talk/solid-the-first-five-principles-of-object-oriented- 디자인 .

SRP와 관련된 예제에서 그는 몇 가지 모양 클래스 (원과 사각형)와 여러 모양의 총 면적을 계산하도록 설계된 클래스의 예를 제공합니다.

첫 번째 예에서 그는 면적 계산 클래스를 작성하고 출력을 HTML로 리턴합니다. 나중에 그는 대신 JSON으로 표시하고 영역 계산 클래스를 변경해야한다고 결정합니다.

이 예제의 문제점은 영역 계산 클래스가 모양 영역을 계산하고 해당 영역을 표시하는 것입니다. 그런 다음 영역을 표시하기 위해 특별히 설계된 다른 클래스를 사용하여이 작업을 수행하는 더 좋은 방법을 사용합니다.

이것은 간단한 예제이며 코드 스 니펫이있는 기사를보다 쉽게 ​​이해할 수 있지만 SRP의 핵심 아이디어를 보여줍니다.

우선, 당신이 가지고있는 것은 실제로 두 가지 별도의 문제입니다 : 클래스에 넣을 메소드의 문제와 인터페이스 팽창의 문제입니다.

인터페이스

이 인터페이스가 있습니다 :

public Interface CustomerCRUD
{
  public void Create(Customer customer);
  public Customer Read(int CustomerID);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

아마도 CustomerCRUD인터페이스에 맞는 여러 클래스 (인터페이스가 필요하지 않음)와 do_crud(customer: CustomerCRUD)적합한 객체를 취하는 일부 함수가 있다고 가정합니다. 그러나 당신은 이미 SRP를 깨뜨 렸습니다. 당신은이 네 가지 별개의 작업들을 하나로 묶었습니다.

나중에 데이터베이스 뷰에서 작업한다고 가정 해 봅시다. 데이터베이스보기가 단지Read 에 대해 사용 가능한 방법을. 그러나 do_query_stuff(customer: ???)완전한 테이블이나 뷰에서 연산자를 투명하게 작성하는 함수를 작성하려고합니다 . 결국이 Read방법 만 사용합니다 .

인터페이스를 만드십시오

공용 인터페이스 CustomerReader {공용 고객 읽기 (customerID : int)}

CustomerCrud인터페이스를 다음 과 같이 고려하십시오 .

public interface CustomerCRUD extends CustomerReader
{
  public void Create(Customer customer);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

그러나 끝이 없습니다. 만들 수는 있지만 업데이트 할 수없는 개체가있을 수 있습니다.이 토끼 구멍은 너무 깊습니다. 단일 책임 원칙을 준수하는 유일한 방법은 모든 인터페이스에 정확히 하나의 메소드를 포함시키는 것 입니다. Go는 실제로 내가 본 것에서이 방법론을 따릅니다. 대부분의 인터페이스에는 단일 함수가 포함되어 있습니다. 두 함수를 포함하는 인터페이스를 지정하려면 두 가지 기능을 결합한 새 인터페이스를 어색하게 만들어야합니다. 곧 인터페이스의 폭발적인 폭발이 일어납니다.

이 혼란을 피하는 방법은 인터페이스 (공칭 서브 타이핑의 형태) 대신 구조적 서브 타이핑 (예 : OCaml에서 구현)을 사용하는 것입니다. 우리는 인터페이스를 정의하지 않습니다. 대신 간단히 함수를 작성할 수 있습니다

let do_customer_stuff customer = customer.read ... customer.update ...

우리가 좋아하는 방법을 호출합니다. OCaml은 형식 유추를 사용하여 이러한 메서드를 구현하는 모든 개체를 전달할 수 있는지 확인합니다. 이 예에서는 customer유형 이 결정 <read: int -> unit, update: int -> unit, ...>됩니다.

클래스

인터페이스 혼란을 해결합니다 . 그러나 여전히 여러 메소드를 포함하는 클래스를 구현해야합니다. 예를 들어, 우리는 두 개의 서로 다른 클래스를 생성해야 CustomerReader하고 CustomerWriter? 테이블을 읽는 방법을 변경하려면 (예 : 데이터를 가져 오기 전에 응답을 redis로 캐시하지만) 이제는 어떻게 작성됩니까? 당신이 따르는 경우 이 논리적 결론을 추론의 사슬을, 당신은 함수형 프로그래밍에 불가분 리드입니다 :)

내 마음에 오는 SRP에 가장 가까운 것은 사용 흐름입니다. 특정 클래스에 대한 명확한 사용 흐름이 없으면 클래스에 디자인 냄새가있을 수 있습니다.

사용 흐름은 주어진 메소드 호출 승계로 예상되는 (따라서 테스트 할 수있는) 결과를 제공합니다. 기본적으로 IMHO를 사용하는 유스 케이스로 클래스를 정의하므로 모든 프로그램 방법론이 구현보다 인터페이스에 중점을 둡니다.

여러 요구 사항을 변경하고 구성 요소를 변경할 필요가 없습니다 .

그러나 SOLID에 대해 처음들을 때 언뜻 이해한다는 점을 잘 알고 있습니다.

SRP 와 YAGNI 가 서로 모순 될 수 있다는 많은 의견이 있지만 TDD (GOOS, London School) 에서 시행하는 YAGN I 는 고객의 관점에서 내 구성 요소를 생각하고 디자인하도록 가르쳐주었습니다. 나는 클라이언트가 원하는 것을 최소한으로하는 것, 즉 얼마나 적은 것을해야하는지에 따라 인터페이스를 디자인하기 시작 했다 . 그리고 그 운동은 TDD에 대한 지식 없이도 수행 될 수 있습니다.

나는 밥 아저씨가 묘사 한 기술을 좋아합니다 (슬프게도 기억할 수는 없습니다).

이 수업은 무엇을합니까?

귀하의 답변에 And 또는 Or 중 하나가 포함되어 있습니까?

그렇다면 답변의 해당 부분을 추출하십시오.

이 기술은 절대적이며 @svidgen이 말했듯이 SRP 는 판단 요청이지만 새로운 것을 배우면 절대적인 것이 가장 좋으며 항상 무언가 를하는 것이 더 쉽습니다 . 분리하지 않는 이유를 확인하십시오. 교양 추정은하고 있지 어떻게가 모르기 때문에. 이것은 예술이며 경험이 필요합니다.

SRP 에 대해 이야기 할 때 많은 답변이 디커플링에 대한 논쟁을하는 것처럼 보입니다 .

SRP는 것입니다 하지 변화가 종속성 그래프를 전파하지 않도록 할 수 있습니다.

이론적으로 SRP 가 없으면 의존성이 없습니다 ...

한 번의 변경으로 인해 응용 프로그램에서 많은 부분이 변경되지 않아야하지만 그에 대한 다른 원칙이 있습니다. 그러나 SRP 는 공개 폐쇄 원칙을 개선합니다 . 이 원리는 추상화에 관한 것이지만, 작은 추상화는 재 구현하기가 더 쉽다 .

따라서 SOLID 전체를 교육 할 때 요구 사항이 변경 될 때 SRP를 사용하면 코드를 적게 변경할 수 있으며 실제로는 새 코드를 적게 작성할 수 있습니다 .

그것에 대한 명확한 대답은 없습니다. 질문은 좁지 만 설명은 아닙니다.

제게는 원한다면 Occam 's Razor와 같은 것입니다. 현재 코드를 측정하려고 할 때 이상적입니다. 단순하고 간단한 단어로 정리하기는 어렵습니다. 또 다른 은유는»하나의 주제«는 추상적이며, 즉 이해하기 어려운»단일 책임«입니다. 세 번째 설명은 한 단계의 추상화를 다루는 것이다.

그것은 실제로 무엇을 의미합니까?

최근에는 주로 두 단계로 구성된 코딩 스타일을 사용합니다.

1 단계는 창조적 혼돈으로 가장 잘 묘사됩니다. 이 단계에서는 생각이 흐를 때 코드를 작성합니다.

2 단계는 완전히 반대입니다. 허리케인 후 청소하는 것과 같습니다. 가장 많은 노력과 훈련이 필요합니다. 그런 다음 디자이너의 관점에서 코드를 봅니다.

나는 주로 파이썬에서 일하고 있는데 나중에 객체와 클래스를 생각할 수 있습니다. 첫 번째 단계 I- 함수 만 작성하고 다른 모듈에서 거의 무작위로 전파합니다. 에서 단계 II 내가가는 일이있어 후에, 나는 어떤 모듈을 거래하는 솔루션의 부분에 대해 자세히 살펴 있습니다. 그리고 모듈을 살펴보면서 주제가 나에게 등장합니다. 일부 기능은 주제별로 관련되어 있습니다. 이것은 수업에 좋은 후보입니다 . 그리고 함수를 클래스로 바꾼 후-거의 들여 쓰기 self로 파이썬에서 매개 변수 목록에 추가 합니다.)-나는 SRPOccam의 면도기와 같은 기능을 사용하여 다른 모듈과 클래스에 기능을 제거합니다.

현재 예는 다른 날에 작은 내보내기 기능을 작성하는 것일 수 있습니다 .

지퍼 에 csv , excel 및 결합 된 excel 시트 가 필요했습니다.

일반 기능은 각각 세 가지 보기 (= 기능)로 수행되었습니다 . 각 함수는 필터를 결정하는 일반적인 방법과 데이터를 검색하는 두 번째 방법을 사용했습니다. 그런 다음 각 기능에서 내보내기 준비가 수행되어 서버에서 응답으로 전달되었습니다.

너무 많은 추상화 레벨이 혼합되었습니다.

I) 수신 / 발신 요청 / 응답 처리

II) 필터 결정

III) 데이터 검색

IV) 데이터 변환

쉬운 단계는 exporter첫 번째 단계에서 레이어 II-IV를 처리 하기 위해 하나의 추상화 ( ) 를 사용하는 것 입니다.

요청 / 응답을 다루는 주제 만 남았습니다 . 동일한 추상화 수준에서 요청 매개 변수 를 추출 하는 것이 좋습니다. 그래서 저는이 관점에서 "책임"을 가지고있었습니다 .

둘째, 수출 업체를 분리해야하는데, 우리가 보았 듯이 적어도 3 개의 다른 추상화 계층으로 구성되었습니다.

결정 필터 기준 및 실제 retrival는 거의 동일한 추상화 레벨 (필터는 데이터의 적절한 서브 세트를 얻기 위하여 필요하다)에있다. 이러한 수준은 데이터 액세스 계층 과 같은 것으로 설정되었습니다 .

다음 단계에서는 실제 내보내기 메커니즘을 따로 분리했습니다. 임시 파일에 쓰기가 필요한 경우 디스크에 데이터를 실제로 쓰기위한 것과 실제 형식을 처리하는 다른 두 가지 "책임"으로 나누었습니다.

클래스와 모듈의 형성과 함께, 상황이 더 명확 해졌고, 무엇이 어디에 속해 있는지가 명확 해졌습니다. 그리고 수업 이 너무 많은지 여부는 항상 잠재 질문 입니다.

각 학급의 책임을 어떻게 결정하고 SRP와 관련하여 책임을 어떻게 정의합니까?

따라야 할 레시피를 제공하기는 어렵습니다. 물론, 나는 한 단계의 추상화 추상화를 반복 할 수있다.

대부분 나를 위해 그것은 현재 디자인으로 이어지는 일종의 "예술적 직관"입니다. 아티스트가 점토를 조각하거나 그림을 그리는 것처럼 코드를 모델링합니다.

내가 코딩 밥 로스 라고 상상해보십시오 .)

SRP를 따르는 코드를 작성하려고 시도하는 것 :

• 해결해야 할 특정 문제를 선택하십시오.
• 이를 해결하는 코드를 작성하고 한 가지 방법으로 모든 것을 작성하십시오 (예 : main);
• 코드를 신중하게 분석하고 비즈니스를 기반으로 수행중인 모든 작업에서 볼 수있는 책임을 정의하십시오 (이는 비즈니스 / 프로젝트 / 고객에 따라 결정되는 주관적인 부분입니다).
• 모든 기능은 이미 구현되어 있습니다. 다음은 코드 구성 일뿐입니다 (이 방법에서는 추가 기능이나 메커니즘이 구현되지 않습니다).
• 이전 단계에서 정의한 책임 (비즈니스 및 "변경해야하는 한 가지 이유"아이디어를 기반으로 정의 된 책임)에 따라 각각에 대해 별도의 클래스 또는 메소드를 추출하십시오.
• 이 방법은 SPR에만 관심이 있습니다. 이상적으로는 다른 원칙도 준수하기위한 추가 단계가 있어야합니다.

예:

문제 : 사용자로부터 두 개의 숫자를 가져 와서 합계를 계산하고 결과를 사용자에게 출력하십시오.

//first step: solve the problem right away
static void Main(string[] args)
{
    Console.WriteLine("Number 1: ");
    int firstNumber = Convert.ToInt32(Console.ReadLine());

    Console.WriteLine("Number 2: ");
    int secondNumber = Convert.ToInt32(Console.ReadLine());

    int result = firstNumber + secondNumber;

    Console.WriteLine("Hi there! The result is: {0}", result);

    Console.ReadLine();
}

다음으로 수행해야 할 작업을 기반으로 책임을 정의하십시오. 이것에서 적절한 클래스를 추출하십시오.

//Responsible for getting two integers from the user
class Input {
    public int FirstNumber { get; set; }
    public int SecondNumber { get; set; }
    public void Read() {
        Console.WriteLine("Number 1: ");
        FirstNumber = Convert.ToInt32(Console.ReadLine());

        Console.WriteLine("Number 2: ");
        SecondNumber = Convert.ToInt32(Console.ReadLine());
    }
}

//Responsible for calculating the sum of two integers
class SumOperation {
    public int Result { get; set; }
    public void Calculate(int a, int b) {
        Result = a + b;
    }
}

//Responsible for the output of some value to the user
class Output {
    public void Write(int result) {
        Console.WriteLine("Hello! The result is: {0}", result);
    }
}

리팩토링 된 프로그램은 다음과 같습니다.

//Program: responsible for main execution.
//Gets two numbers from user and output their sum.
static void Main(string[] args)
{
    var input = new Input();
    input.Read();

    var operation = new SumOperation();
    operation.Calculate(input.FirstNumber, input.SecondNumber);

    var output = new Output();
    output.Write(operation.Result);

    Console.ReadLine();
}

참고 : 이 매우 간단한 예는 SRP 원칙 만 고려합니다. 다른 원칙 (예 : "L"-코드는 생성이 아닌 추상화에 의존해야 함)을 사용하면 코드에 더 많은 이점을 제공하고 비즈니스 변경에 대한 유지 관리가 더 쉬워집니다.

Robert C. Martins 는 2017 년 9 월 10 일에 출판 된 Clean Architecture : A Craftsman 's Guide to Software Structure and Design ( 2017 년 9 월 10 일 발행)에서 62 페이지에 다음과 같이 썼습니다.

역사적으로 SRP는 다음과 같이 설명되었습니다.

모듈에는 변경해야 할 단 하나의 이유가 있어야합니다

사용자와 이해 관계자를 만족시키기 위해 소프트웨어 시스템이 변경되었습니다. 이러한 사용자와 이해 관계자 는 "변경 이유"입니다. 그 원칙이 말하는 것입니다. 실제로, 우리는 다음과 같이 원칙을 바꾸어 쓸 수 있습니다 :

모듈은 한 명의 사용자 또는 이해 관계자에게만 책임을 져야합니다

불행히도, "사용자"와 "이해 관계자"라는 단어는 실제로 여기서 사용하기에 올바른 단어가 아닙니다. 제정신 방식으로 시스템을 변경하기를 원하는 둘 이상의 사용자 또는 이해 관계자가있을 수 있습니다. 대신 우리는 그룹을 언급하고 있습니다. 한 명 이상의 사람들이 그러한 변화를 필요로합니다. 우리는 그 그룹을 배우 로 지칭 할 것입니다 .

따라서 SRP의 최종 버전은 다음과 같습니다.

모듈은 오직 한 명의 액터 만 담당합니다.

따라서 이것은 코드에 관한 것이 아닙니다. SRP는 요구 사항 및 비즈니스 요구의 흐름을 제어하는 ​​것입니다.