수업이 단일 책임 원칙을 충족하는지 확인하는 방법은 무엇입니까?

단일 책임 원칙은 높은 응집력 원칙을 기반으로합니다. 이 둘의 차이점은 높은 응집력을 가진 클래스는 밀접하게 관련된 일련의 책임을 특징으로하며 SRP를 준수하는 클래스는 하나의 책임 만 갖습니다.

그러나 특정 클래스가 일련의 책임을 지니고 있고 그에 따라 매우 응집력이 있는지 아니면 하나의 책임 만 가지고 SRP를 준수하는지 여부를 어떻게 결정합니까? 다시 말해서, 일부는 클래스를 매우 세분화 한 것으로 간주 할 수 있고 (그러므로 클래스가 SRP를 준수한다고 생각할 수 있기 때문에) 더 주관적이지 않습니까?

왜 그렇습니까? 그것은 매우 주관적이며, 프로그래머들이 직면하는 열렬한 적대 토론의 주제입니다.

실제로 답변이 하나도 없으며 소프트웨어가 복잡 해짐에 따라 답변이 변경 될 수 있습니다. 한 번 잘 정의 된 작업이었던 것은 결국 여러 가지 잘못 정의 된 작업이 될 수 있습니다. 그것은 항상 문지름입니다. 프로그램을 작업으로 나누는 적절한 방법을 어떻게 선택합니까?

내가 줄 수있는 유일한 조언은 이것입니다 : 당신과 당신의 동료들의 최선의 판단을 사용하십시오. 그리고 실수를 빨리 잡으면 실수를 바로 잡을 수 있다는 것을 기억하십시오.

SRP 가 첫 번째 인 SOLID 원칙 을 만든 Bob Martin (Bob Uncle Bob) 은 이에 대해 말합니다.

수업은 한 가지 이유 만 변경해야합니다

여러 가지 이유가있는 경우 SRP를 준수하지 않습니다.

몇 가지 규칙을 제시 할 수 있습니다.

• 수업 이름을 지정하는 것이 얼마나 쉬운가요? 수업의 이름을 정하기가 어렵다면 아마도 너무 많은 일을하고있을 것입니다.
• 수업에는 몇 개의 공개 방법이 있습니까? 7 +/- 2는 좋은 경험 법칙입니다. 수업에 그 이상이 있다면 여러 수업으로 나누는 것에 대해 생각해야합니다.
• 별도의 상황에서 사용되는 응집력있는 공개 방법 그룹이 있습니까?
• 개인 메소드 또는 데이터 멤버는 몇 개입니까? 클래스의 내부 구조가 복잡한 경우 내부가 별도의 작은 클래스로 패키지화되도록 리팩토링해야합니다.
• 가장 쉬운 경험 법칙 : 수업 규모는 얼마나됩니까? 수백 줄이 넘는 단일 클래스를 포함하는 C ++ 헤더 파일이 있으면 분할해야합니다.

단일 책임 원칙에 따르면 각 소프트웨어 모듈에는 변경해야 할 이유가 하나만 있어야합니다. 밥 아저씨는 최근 기사에서 "변경 이유"를 설명했습니다.

그러나이 원칙에 대해 생각할 때 변화의 이유는 사람이라는 것을 기억하십시오. 변경을 요청하는 사람들입니다. 그리고 많은 사람들이 다른 이유로 관심을 갖는 코드를 서로 혼합하여 사람들이나 자신을 혼동하고 싶지 않습니다.

그는 더 예와 개념을 설명 HERE .

이에 답하려면 물러서서 단일 책임 원칙 의 의도 를 고려하십시오 . 처음에 권장되는 설계 원칙은 무엇입니까?

이 원칙의 목적은 코드베이스를 "구획화"하는 것이므로 단일 "책임"과 관련된 코드는 단일 단위로 분리됩니다. 이를 통해 코드를보다 쉽게 ​​찾고 이해할 수 있으며 더 중요한 것은 "책임"을 변경하면 단일 코드 단위에만 영향을 미칩니다.

시스템에서 절대로 원하지 않는 것은 하나의 작은 기회로 인해 코드의 관련이없는 다른 부분이 작동하지 않거나 변경 될 때입니다. SRP는 버그와 변경 사항을 격리하는 데 도움이됩니다.

그렇다면 "책임"이란 무엇입니까? 다른 변화와는 독립적으로 변화 할 수있는 것입니다. 일부 설정을 XML 구성 파일에 저장하고 파일에서 다시 읽을 수있는 프로그램이 있다고 가정하십시오. 이것이 단일 책임입니까, 아니면 "로드"와 "저장"이 서로 다른 책임입니까? 파일 형식이나 구조를 변경하려면로드 및 저장 논리를 모두 변경해야합니다. 따라서 단일 클래스로 표시해야하는 단일 책임입니다. 이제 일부 데이터를 CVS, Excel 및 XML 형식으로 내보낼 수있는 앱을 고려하십시오. 이 경우 한 형식이 다른 형식에 영향을주지 않고 변경 될 수 있다고 쉽게 상상할 수 있습니다. CVS 형식으로 구분 기호를 변경하기로 결정한 경우 Excel 출력에 영향을 미치지 않습니다.

OO는 클래스는 기능의 데이터 그룹입니다. 이 정의는 주관적인 해석을위한 충분한 여지를 남겨둔다.

우리는 클래스가 명확하고 쉽게 정의되어야한다는 것을 알고 있습니다. 그러나 이러한 클래스를 정의하려면 클래스가 전체 디자인에 어떻게 적합한 지에 대한 명확한 개념이 있어야합니다. 역설적으로 안티 패턴으로 간주되는 폭포 유형 요구 사항이 없으면 달성하기가 어렵습니다.

MVC와 같은 대부분의 경우 작동하는 아키텍처로 클래스 디자인을 구현할 수 있습니다. MVC 응용 프로그램에서 우리는 데이터, 사용자 인터페이스 및이 둘의 통신 요구 사항 만 있다고 가정합니다.

기본 아키텍처를 사용하면 단일 책임 규칙이 위반되는 사례를 쉽게 식별 할 수 있습니다. EG 사용자 컨트롤 인스턴스를 모달로 전달합니다.

그냥 토론을 위해, 나는로부터 클래스 나타납니다 JUCE 라는 AudioSampleBuffer을 . 이제이 클래스는 오디오 스 니펫 (또는 아마도 긴 스 니펫)을 보유하기 위해 존재합니다. 그것은 채널 수, 샘플 수 (채널 당)를 알고 있으며 가변 숫자 표현이나 단어 화가 아니라 32 비트 IEEE float에 최선을 다하고 있습니다 (그러나 그것은 문제가되지 않습니다). numChannel 또는 numSamples 및 특정 채널에 대한 포인터를 가져올 수있는 멤버 함수가 있습니다. AudioSampleBuffer를 더 길거나 더 짧게 만들 수 있습니다. 나는 전자가 패드를 자르는 동안 전자는 0 패드를 가정합니다.

이 클래스에는 JUCE가 사용하는 특수 힙에 공간을 할당하는 데 사용되는 몇 개의 개인 구성원이 있습니다.

그러나 이것은 AudioSampleBuffer가 누락 된 것입니다 (그리고 Jules와 그것에 대해 몇 가지 토론을했습니다) SampleRate. 어떻게 그것을 놓칠 수 있습니까?

AudioSampleBuffer가 수행해야 할 단일 책임은 샘플이 나타내는 실제 오디오를 적절히 표현하는 것입니다. 사운드 파일을 읽거나 스트림에서 AudioSampleBuffer를 입력 할 때 AudioSampleBuffer와 함께 샘플 속도를 알아야하는 처리 방법 (예 : 필터)에이를 전달해야하는 추가 매개 변수가 있습니다. 결국, 방법에 재생 들을 수 버퍼를 (또는 다른 곳으로 스트림). 도대체 무엇이.

그러나 당신이해야 할 일은 AudioSampleBuffer에 살고있는 특정 오디오에 고유 한이 SampleRate를 계속 어디서나 전달하는 것입니다. 프로그래머가 다른 작업을 알지 못했기 때문에 상수 44100.0f가 함수에 전달되는 코드를 보았습니다 .

이것은 단일 책임을 이행하지 못한 예입니다.

말한 내용에 따라 구체적인 방법을 사용할 수 있습니다. 응집력이 높으면 응집력을 측정 할 수있는 단일 책임이 있습니다. 최대 응집력 클래스에는 모든 메소드에 사용 된 모든 필드가 있습니다. 최대한의 응집력있는 수업이 항상 가능하지는 않지만 여전히 최선을 다하는 것이 바람직하지는 않습니다. 이 클래스 디자인 목표를 가지면 클래스에 많은 메서드 나 필드를 가질 수 없다고 추론하기가 쉽습니다 (일부는 최대 7 명).

또 다른 방법은 실제 객체를 따르는 모델 인 OOP의 순수한 기본입니다. 실제 객체의 책임을 보는 것이 훨씬 쉽습니다. 그러나 실제 객체가 너무 복잡한 경우에는 각각의 고유 한 책임이있는 여러 포함 된 객체로 분리합니다.