단일 책임 원칙 명확화

단일 책임 원칙에 따르면 클래스는 한 가지만 수행해야합니다. 어떤 경우는 꽤 분명합니다. 그러나 특정 추상화 수준에서 볼 때 "하나의 것"처럼 보이는 것이 낮은 수준에서 볼 때 여러 가지 일 수 있기 때문에 다른 것들은 어렵습니다. 또한 단일 책임 원칙이 더 낮은 수준에서 과도하게 분리되고 자세한 라비올리 코드를 준수하면 더 많은 라인이 모든 문제에 대한 작은 클래스를 만들고 실제 문제를 해결하는 것보다 주변에 정보를 제공하는 데 소비되는 더 많은 줄이 생길 수 있습니다.

"한 가지"의 의미를 어떻게 설명 하시겠습니까? 클래스가 실제로 "한 가지"이상을 수행한다는 구체적인 징후는 무엇입니까?

Robert C. Martin (Uncle Bob) 이 Single Responsibility Principle (PDF에 연결 )을 재건 하는 방식이 정말 마음에 듭니다 .

수업이 바뀌어야하는 이유는 하나 이상이어야합니다.

그것은 전통적인 "한 가지만해야한다"라는 정의와 미묘하게 다르며, 나는 당신이 당신의 수업에 대해 생각하는 방식을 바꾸도록 강요하기 때문에 이것을 좋아합니다. "이것이 한 가지 일을하고 있는가?"에 대해 생각하는 대신에, 무엇을 바꿀 수 있는지, 그리고 그러한 변화가 당신의 수업에 어떤 영향을 미치는지 생각하십시오. 예를 들어, 데이터베이스가 변경되면 클래스를 변경해야합니까? 출력 장치 (예 : 화면, 모바일 장치 또는 프린터)가 변경되면 어떻습니까? 다른 많은 방향의 변화로 인해 수업을 변경해야하는 경우, 수업에 너무 많은 책임이 있다는 표시입니다.

관련 기사에서 Bob 아저씨는 다음과 같이 결론을 내립니다.

SRP는 가장 간단한 원칙 중 하나이며 가장 잘 이해하기 어려운 원칙 중 하나입니다. 결합 된 책임은 우리가 자연스럽게하는 것입니다. 이러한 책임을 찾아서 분리하는 것은 소프트웨어 설계가 실제로하는 것의 많은 부분입니다.

SRP가 어떤 문제를 해결하려고 노력하고 있습니까? SRP는 언제 도움이 되나요? 내가 생각해 낸 것은 다음과 같습니다.

다음과 같은 경우 클래스 외부에서 책임 / 기능을 리팩터링해야합니다.

1) 기능이 중복되었습니다 (DRY)

2) 코드 이해를 돕기 위해 코드에 다른 수준의 추상화가 필요하다는 것을 알게되었습니다 (KISS)

3) 도메인 전문가가 기능의 일부를 다른 구성 요소 (유비쿼터스 언어)와 분리 한 것으로 이해함

다음과 같은 경우 클래스 외부에서 책임을 리팩터링하지 않아야합니다.

1) 중복 된 기능이 없습니다.

2) 기능은 수업의 맥락 밖에서는 의미가 없습니다. 다시 말해, 클래스는 기능을 이해하기 쉬운 컨텍스트를 제공합니다.

3) 도메인 전문가에게는 그러한 책임에 대한 개념이 없습니다.

SRP가 광범위하게 적용되면 우리는 한 종류의 복잡성 (내부에서 너무 많은 방식으로 수업의 머리 또는 꼬리를 만들려고 시도)을 다른 종류 (모든 공동 작업자 / 수준의 이 클래스들이 실제로 무엇을하는지 파악하기 위해 추상화).

확실하지 않은 경우에는 그대로 두십시오! 명확한 사례가있는 경우 언제든지 나중에 리팩터링 할 수 있습니다.

어떻게 생각해?

나는 그것에 대한 객관적인 규모가 있는지는 모르지만 이것을 줄 것입니다. 나는 당신이 너무 멀리 분해를 취할 수 있다고 동의하지만 그것에 대해 강력하고 빠른 규칙을 따르지 않을 것입니다.

답은 정의에있다

당신 이 책임을 정의 하는 것은 궁극적으로 당신에게 경계를줍니다.

예:

송장 을 표시 하는 책임이있는 구성 요소가 있습니다. 이 경우 더 이상 추가하기 시작하면 원칙을 위반합니다.

반면에 경우에 나는 책임 말했다 경우 처리 송장을 - (예 : 인쇄 여러 개의 작은 기능을 추가> 송장 업데이트 송장을 모두 그 경계에 있습니다).

해당 모듈 처리하기 시작한다면 어떤 외부 기능 송장을 , 다음은 그 경계의 외부 것이다.

나는 항상 두 가지 수준으로 봅니다.

• 내 방법이 한 가지 일만하고 잘 수행하는지 확인하십시오.
• 클래스를 한 가지를 잘 나타내는 메소드의 논리적 (OO) 그룹화로 본다

따라서 Dog라는 도메인 객체와 같은 것입니다.

Dog내 수업이지만 개는 많은 일을 할 수 있습니다! 나는 다음과 같은 방법이있을 수 있습니다 walk(), run()그리고 bite(DotNetDeveloper spawnOfBill)(죄송 저항 할 수 없었다; p)를.

경우 Dog다루기로되고 그 다음 나는 그 방법의 그룹이 같은 같은 다른 클래스에서 함께 모델링 할 수있는 방법에 대해 생각하는 것 Movement내 포함 할 수 클래스 walk()와 run()방법을.

단단하고 빠른 규칙은 없으며 OO 디자인은 시간이 지남에 따라 진화합니다. 명확한 컷 인터페이스 / 퍼블릭 API뿐만 아니라 한 가지 일과 한 가지 일을 잘 수행하는 간단한 메소드를 사용하려고합니다.

나는 수업의 라인을 따라 그것을 한 번만 표현 해야합니다 . Karianna의 예를 @ 적절한하기 위해, 나는이 Dog방법을 가지고 클래스를 walk(), run()하고 bark(). 내가하기위한 방법을 추가하지 않을거야 meaow(), squeak(), slither()또는 fly()그 개는 할 일이 없기 때문에. 그것들은 다른 동물들이하는 일이며, 다른 동물들은 그들을 대표하는 자신의 수업을 가질 것입니다.

(당신의 개를 경우 BTW, 않습니다 비행, 그때는 아마 창에서 그를 던지는 중지해야합니다).

클래스는 자체 추상화 수준에서 볼 때 한 가지 작업을 수행해야합니다. 의심 할 여지없이 추상적 인 수준에서 많은 일을합니다. 이것은 클래스가 프로그램을 유지 관리하기 쉽게 만드는 방법입니다. 프로그램을 자세히 조사 할 필요가 없으면 구현 세부 사항을 숨 깁니다.

나는 이것을 테스트하기 위해 클래스 이름을 사용합니다. 클래스에 설명이 짧은 이름을 줄 수 없거나 해당 이름에 "And"와 같은 단어가 있으면 단일 책임 원칙을 위반 한 것입니다.

내 경험상,이 원칙을보다 구체적인 수준으로 유지하는 것이 더 쉽습니다.

하나의 독특한 rôle을 갖는 것 입니다.

각 클래스는 역할 이름으로 다시 시작해야합니다. 역할은 사실 문맥과 관련된 동사의 집합입니다.

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

파일은 파일의 액세스를 제공합니다. FileManager는 파일 객체를 관리합니다.

파일에서 하나의 자원에 대한 자원 보유 데이터. ResourceManager는 모든 자원을 보유하고 제공합니다.

여기서 "관리"와 같은 일부 동사는 다른 동사 집합을 의미합니다. 동사는 대부분 클래스보다 함수로 생각하는 것이 좋습니다. 동사가 자신의 공통된 맥락을 가진 너무 많은 행동을 암시한다면, 그 자체가 클래스가되어야합니다.

따라서 아이디어는 고유 한 역할을 정의하여 클래스가 무엇을 수행하는지에 대한 간단한 아이디어를 가질 수 있도록하는 것입니다. 이는 여러 하위 역할 (멤버 오브젝트 또는 다른 오브젝트에 의해 수행됨)의 집합 일 수 있습니다.

나는 종종 다른 여러 클래스가있는 Manager 클래스를 빌드합니다. 팩토리, 레지스트리 등과 같은 일종의 그룹 장, 오케스트라 장과 같은 Manager 클래스를 참조하여 다른 사람들이 함께 협력하여 높은 수준의 아이디어를 얻도록 안내하십시오. 그는 하나의 역할을 가지고 있지만 내부의 다른 고유 한 역할을 수행하는 것을 의미합니다. 또한 회사 구성 방식과 같이 볼 수 있습니다. CEO는 순수한 생산성 수준에서 생산적인 회사는 아니지만, 그렇지 않은 경우에는 제대로 협력 할 수 없습니다. 그것이 그의 역할입니다.

디자인 할 때 고유 한 역할을 식별하십시오. 그리고 각 역할에 대해 다른 역할에서 잘릴 수 없는지 다시 확인하십시오. 그렇게하면 Manager가 객체를 작성하는 방식을 간단하게 변경해야하는 경우 간단히 Factory를 변경하고 안심하십시오.

SRP는 클래스를 나누는 것뿐만 아니라 기능을 위임하는 것입니다.

위에서 사용 된 Dog 예제에서 DogBarker, DogWalker 등과 같은 3 개의 개별 클래스 (낮은 응집력)를 갖도록 SRP를 정당화로 사용하지 마십시오. 대신 클래스의 메소드 구현을보고 "너무 많이 알고 있는지"결정하십시오. 여전히 dog.walk ()를 가질 수 있지만, walk () 메소드는 다른 클래스에 걷기 수행 방법에 대한 세부 사항을 위임해야합니다.

실제로 우리는 Dog 클래스가 변경 될 수있는 한 가지 이유를 허용합니다 : Dogs가 변경되기 때문입니다. 물론, 이것을 다른 SOLID 원리와 결합하면 Dog (개방 / 폐쇄)를 변경하지 않고 새로운 기능을 위해 Dog를 확장 할 수 있습니다. 그리고 IMove 및 IEat와 같은 종속성을 주입합니다. 물론 이러한 별도의 인터페이스 (인터페이스 분리)를 만들어야합니다. 개가 버그를 발견하거나 개가 근본적으로 변경된 경우에만 개가 변경됩니다 (Liskov Sub, 확장하지 않은 다음 동작 제거).

SOLID의 최종 효과는 기존 코드를 수정하는 것보다 새 코드를 더 자주 작성한다는 것입니다.

그것은 모두 책임의 정의와 그 정의가 코드 유지에 어떤 영향을 미치는지에 달려 있습니다. 모든 것이 한 가지로 요약되며 디자인이 코드를 유지하는 데 도움이되는 방식입니다.

그리고 누군가가 말했듯이 "물을 걷거나 주어진 사양으로 소프트웨어를 설계하는 것은 쉽다"고 말했다.

따라서 책임을 좀 더 구체적으로 정의하고 있다면 변경할 필요가 없습니다.

때로는 책임이 눈에 띄게 드러날 지 모르지만 때로는 미묘 할 수도 있으므로 신중하게 결정해야합니다.

catchThief ()라는 Dog 클래스에 다른 책임을 추가한다고 가정합니다. 이제는 다른 책임을지게 될 수도 있습니다. 내일, 개가 도둑을 잡는 방식이 경찰서에 의해 변경되어야한다면, 개 수업이 변경되어야합니다. 이 경우 다른 서브 클래스를 작성하고 이름을 ThiefCathcerDog로하는 것이 좋습니다. 그러나 다른 관점에서, 어떤 상황에서도 변화하지 않을 것이라고 확신하거나 catchThief가 구현 된 방식이 외부 매개 변수에 의존하는 경우이 책임을 갖는 것이 좋습니다. 책임이 현저하게 이상하지 않으면 사용 사례에 따라 신중하게 결정해야합니다.

"변경해야하는 한 가지 이유"는 시스템을 사용하는 사람에 따라 다릅니다. 각 액터에 대해 사례를 사용하고 가능한 변경 사항 목록을 작성하십시오. 각 가능한 사용 사례 변경에 대해 한 클래스 만 해당 변경의 영향을 받도록하십시오. 완전히 새로운 사용 사례를 추가하는 경우 클래스를 확장하기 만하면됩니다.