단일 책임 원칙. 보이는 것만큼 간단하지 않다

단일 책임 원칙, 단일 책임 원칙이라고도 합니다.
일명 균일 가변성의 원리 - 이해하기 매우 미끄럽고 프로그래머 인터뷰에서 매우 긴장된 질문입니다.

이 원리에 대한 나의 첫 번째 진지한 지인은 첫해 초에 어린 녹색 사람들이 애벌레에서 학생, 즉 실제 학생을 만들기 위해 숲으로 끌려 갔을 때 일어났습니다.

숲속에서 우리는 8~9명으로 구성된 그룹으로 나뉘어서, 그룹의 첫 번째 사람이 보드카를 잔에 붓고 두 번째 사람이 그것을 마신다면 어느 그룹이 보드카 한 병을 가장 빨리 마실 것인지 경쟁을 벌였습니다. 세 번째는 간식을 먹습니다. 작업을 완료한 유닛은 그룹 대기열의 끝으로 이동합니다.

대기열 크기가 XNUMX의 배수인 경우는 SRP를 잘 구현한 것입니다.

정의 1. 단일 책임.

단일 책임 원칙(SRP)의 공식 정의에 따르면 각 엔터티에는 고유한 책임과 존재 이유가 있으며 책임은 하나만 있습니다.

"Drinker"라는 개체를 고려하십시오(술꾼).
SRP 원칙을 구현하기 위해 책임을 세 가지로 나눕니다.

• 하나는 붓는다 (타설작업)
• 한 잔(DrinkUp작업)
• 한 명은 간식을 먹습니다(TakeBiteOperation)

프로세스의 각 참가자는 프로세스의 한 구성 요소, 즉 마시고, 따르고, 간식을 먹는 하나의 원자적 책임을 담당합니다.

음주 구멍은 다음 작업의 외관입니다.

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налить
        _drinkUpOperation.Do() // выпить
        _takeBiteOperation.Do() // закусить
    }
}

이유는 무엇입니까?

인간 프로그래머는 유인원을 위해 코드를 작성하지만 유인원은 부주의하고 멍청하며 항상 서두르고 있습니다. 그는 한 번에 약 3~7개의 용어를 이해하고 이해할 수 있습니다.
술고래의 경우에는 이 세 가지 용어가 있습니다. 그러나 한 장으로 코드를 작성하면 손, 안경, 싸움, 정치에 대한 끝없는 논쟁이 포함될 것입니다. 그리고 이 모든 것이 하나의 메서드에 포함됩니다. 나는 당신이 연습에서 그러한 코드를 본 적이 있다고 확신합니다. 정신에 대한 가장 인도적인 테스트는 아닙니다.

반면에 유인원은 머리 속에서 실제 사물을 시뮬레이션하도록 설계되었습니다. 상상 속에서 그는 그것들을 함께 밀고, 그것들로부터 새로운 물건을 조립하고, 같은 방식으로 분해할 수 있습니다. 오래된 모델 자동차를 상상해보십시오. 상상 속에서 문을 열고 도어 트림의 나사를 풀고 내부에 기어가 있는 창 리프트 메커니즘을 볼 수 있습니다. 그러나 하나의 "목록"에서 기계의 모든 구성 요소를 동시에 볼 수는 없습니다. 적어도 "원숭이 남자"는 그럴 수 없습니다.

따라서 인간 프로그래머는 복잡한 메커니즘을 덜 복잡하고 작동하는 요소 세트로 분해합니다. 그러나 다양한 방법으로 분해될 수 있습니다. 많은 오래된 자동차에서는 공기 덕트가 도어로 들어가고 현대 자동차에서는 잠금 장치 전자 장치의 고장으로 인해 엔진이 시동되지 않아 수리 중에 문제가 될 수 있습니다.

이제, SRP는 어떻게 분해해야 하는지, 즉 어디에 구분선을 그어야 하는지를 설명하는 원리이다..

책임 분담의 원칙, 즉 특정 대상의 임무에 따라 분해할 필요가 있다고 말한다.

원숭이 남자가 분해 중에 얻는 음주와 이점으로 돌아가 보겠습니다.

• 코드는 모든 수준에서 매우 명확해졌습니다.
• 코드는 여러 프로그래머가 동시에 작성할 수 있습니다(각각 별도의 요소를 작성함).
• 자동화된 테스트가 단순화됩니다. 요소가 단순할수록 테스트하기가 더 쉽습니다.
• 코드의 구성이 나타납니다. 교체할 수 있습니다. DrinkUp작업 술고래가 테이블 아래에 액체를 붓는 작업. 또는 붓는 작업을 와인과 물 또는 보드카와 맥주를 섞는 작업으로 대체하세요. 비즈니스 요구 사항에 따라 메서드 코드를 건드리지 않고도 모든 작업을 수행할 수 있습니다. 티플러 액트.
• 이러한 작업을 통해 대식가를 접을 수 있습니다(단지 사용). TakeBit작업), 알코올 중독자(만 사용) DrinkUp작업 병에서 직접 추출) 및 기타 다양한 비즈니스 요구 사항을 충족합니다.

(아, 이건 이미 OCP 원칙인 것 같고, 제가 이 글의 책임을 위반한 것 같습니다)

그리고 물론 단점은 다음과 같습니다.

• 더 많은 유형을 만들어야 합니다.
• 술고래는 평소보다 두 시간 늦게 처음으로 술을 마신다.

정의 2. 통합된 가변성.

허용해주세요, 여러분! 음주 수업에도 단 하나의 책임이 있습니다. 바로 음주입니다! 그리고 일반적으로 "책임"이라는 단어는 매우 모호한 개념입니다. 인류의 운명을 책임지는 사람이 있고, 극지방에서 전복된 펭귄을 키울 책임이 있는 사람이 있다.

drinker의 두 가지 구현을 고려해 보겠습니다. 위에서 언급한 첫 번째 클래스에는 따르기, 마시기, 간식의 세 가지 클래스가 포함되어 있습니다.

두 번째는 "Forward and Only Forward" 방법론을 통해 작성되었으며 해당 방법의 모든 논리를 포함합니다. 행동:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
сlass BrutTippler {
   //...
   void Act(){
        // наливаем
    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))
        throw new OverdrunkException();

    // выпиваем
    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))
        throw new OverdrunkException();

    //Закусываем
    for(int i = 0; i< 3; i++){
        var food = _foodStore.TakeOrDefault();
        if(food==null)
            throw new FoodIsOverException();

        _hand.TryEat(food);
    }
   }
}

외부 관찰자의 관점에서 보면 이 두 클래스는 완전히 똑같아 보이며 "음주"에 대한 동일한 책임을 공유합니다.

착란!

그런 다음 온라인에 접속하여 SRP의 또 다른 정의인 단일 변경 가능성 원칙을 알아봅니다.

SCP는 "모듈에는 변경해야 할 단 하나의 이유가 있습니다.". 즉, “책임은 변화의 이유이다”이다.

(원래 정의를 생각해낸 녀석들은 유인원의 텔레파시 능력에 자신이 있었던 것 같다)

이제 모든 것이 제자리에 놓였습니다. 별도로 붓기, 마시기 및 간식 절차를 변경할 수 있지만 술꾼 자체에서는 예를 들어 마시기 전에 간식을 이동하거나 건배 읽기를 추가하는 등 작업 순서와 구성만 변경할 수 있습니다.

"Forward and Only Forward" 접근 방식에서는 변경할 수 있는 모든 것은 메서드에서만 변경됩니다. 행동. 이것은 논리가 거의 없고 거의 변경되지 않을 때 읽기 쉽고 효과적일 수 있지만 종종 러시아가 NATO에 가입하는 데 필요한 것보다 더 많은 if 문이 포함되어 각각 500줄의 끔찍한 방법으로 끝나는 경우가 많습니다.

정의 3. 변경 사항의 현지화.

술꾼들은 자신이 왜 다른 사람의 아파트에서 깨어났는지, 휴대폰이 어디에 있는지 이해하지 못하는 경우가 많습니다. 이제 자세한 로깅을 추가할 차례입니다.

붓는 과정에 대한 기록을 시작해 보겠습니다.

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Before pour with {_hand} and {_bottle}");
        //Pour business logic ...
        _log.Log($"After pour with {_hand} and {_bottle}");
    }
}

그것을 캡슐화함으로써 타설작업, 우리는 책임과 캡슐화의 관점에서 현명하게 행동했지만 이제는 가변성의 원칙과 혼동하고 있습니다. 변경될 수 있는 작업 자체 외에도 로깅 자체도 변경 가능해집니다. 붓는 작업을 위해 특수 로거를 분리하고 생성해야 합니다.

interface IPourLogger{
    void LogBefore(IHand, IBottle){}
    void LogAfter(IHand, IBottle){}
    void OnError(IHand, IBottle, Exception){}
}

class PourOperation: IOperation{
    PourOperation(IPourLogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.LogBefore(_hand, _bottle);
        try{
             //... business logic
             _log.LogAfter(_hand, _bottle");
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e)
        }
    }
}

세심한 독자는 그것을 알아차릴 것이다. 로그이후, 로그이전 и 오류 시 개별적으로 변경할 수도 있으며 이전 단계와 유사하게 세 가지 클래스가 생성됩니다. PourLogger이전, PourLogger이후 и PourErrorLogger.

그리고 술꾼에 대한 세 가지 작업이 있다는 것을 기억하면 우리는 14개의 로깅 클래스를 얻습니다. 결과적으로 전체 음주 서클은 ​​XNUMX(!!!) 클래스로 구성됩니다.

쌍곡선? 거의 ~ 아니다! 분해 수류탄을 들고 있는 원숭이 남자는 "주입기"를 디캔터, 유리잔, 쏟아지는 조작자, 물 공급 서비스, 분자 충돌의 물리적 모델로 나누고 다음 분기 동안 그는 종속성을 풀려고 노력할 것입니다. 전역 변수. 그리고 내 말을 믿으세요. 그는 멈추지 않을 것입니다.

이 시점에서 많은 사람들은 SRP가 핑크 왕국의 동화라는 결론에 도달하고 국수를 즐기러 떠납니다.

... Srp의 세 번째 정의의 존재에 대해 전혀 배우지 않은 채:

“단일 책임 원칙은 다음과 같습니다. 변화와 유사한 것들은 한 곳에 보관해야 한다". 또는 "함께 변경된 내용은 한 곳에 보관해야 합니다."

즉, 작업 로깅을 변경하면 한 곳에서 변경해야 합니다.

이것은 매우 중요한 점입니다. 위의 SRP에 대한 모든 설명에서는 유형을 분쇄하는 동안 유형을 분쇄해야 한다고 말했기 때문에 즉, 개체 크기에 "상한"을 부과했으며 이제 우리는 이미 "하한"에 대해 이야기하고 있습니다. 다시 말해서, SRP는 "부수면서 부수는 것"을 요구할 뿐만 아니라, 그것을 과하게 하지 말 것 - "연동하는 것을 부수지 말라". 이것은 오컴의 면도날과 유인원의 대결이다!

이제 술꾼의 기분이 좋아질 것입니다. IPourLogger 로거를 세 가지 클래스로 분할할 필요가 없다는 사실 외에도 모든 로거를 하나의 유형으로 결합할 수도 있습니다.

class OperationLogger{
    public OperationLogger(string operationName){/*..*/}
    public void LogBefore(object[] args){/*...*/}       
    public void LogAfter(object[] args){/*..*/}
    public void LogError(object[] args, exception e){/*..*/}
}

그리고 네 번째 유형의 작업을 추가하면 해당 작업에 대한 로깅이 이미 준비되어 있습니다. 그리고 운영 코드 자체가 깨끗하고 인프라 노이즈가 없습니다.

결과적으로 음주 문제를 해결하기 위한 5가지 수업이 있습니다.

• 붓는 작업
• 음주운전
• 전파 방해 작업
• 나무꾼
• 술꾼 외관

각각은 하나의 기능에 대해 엄격하게 책임을 지며 변경 이유도 하나입니다. 변경과 유사한 모든 규칙은 근처에 있습니다.

실제 사례

우리는 B2B 클라이언트를 자동으로 등록하는 서비스를 작성한 적이 있습니다. 그리고 유사한 내용의 200줄에 대해 GOD 방법이 나타났습니다.

• 1C로 이동하여 계정을 만드십시오
• 이 계정으로 결제 모듈로 이동하여 생성하세요.
• 해당 계정을 가진 계정이 메인 서버에 생성되지 않았는지 확인하세요
• 새 계정 생성
• 결제 모듈에 등록 결과를 추가하고 등록 결과 서비스에 1c 번호를 추가합니다.
• 이 테이블에 계정 정보 추가
• 포인트 서비스에서 이 클라이언트에 대한 포인트 번호를 생성합니다. 이 서비스에 1c 계좌 번호를 전달하세요.

그리고 이 목록에는 연결성이 좋지 않은 비즈니스 운영이 약 10개 더 있었습니다. 거의 모든 사람에게 계정 개체가 필요했습니다. 호출의 절반에는 포인트 ID와 클라이언트 이름이 필요했습니다.

한 시간의 리팩토링 후에 우리는 인프라 코드와 계정 작업의 미묘한 차이를 별도의 메서드/클래스로 분리할 수 있었습니다. God 메소드를 사용하면 더 쉬워졌지만, 엉키고 싶지 않은 100줄의 코드가 남아 있었습니다.

불과 며칠 후에야 이 "가벼운" 방법의 본질이 비즈니스 알고리즘이라는 것이 분명해졌습니다. 그리고 기술 사양에 대한 원래 설명은 상당히 복잡했습니다. 그리고 이 방법을 SRP를 위반하는 조각으로 나누려는 시도이며 그 반대의 경우도 마찬가지입니다.

형식주의.

이제 술에 취한 사람을 내버려 둘 시간입니다. 눈물을 닦아주세요. 언젠가는 꼭 다시 돌아올 것입니다. 이제 이 기사에서 얻은 지식을 공식화해 보겠습니다.

형식주의 1. SRP의 정의

1. 각 요소가 한 가지를 담당하도록 요소를 분리합니다.
2. 책임은 “변화의 이유”를 의미합니다. 즉, 각 요소에는 비즈니스 논리 측면에서 변경 이유가 하나만 있습니다.
3. 비즈니스 로직에 대한 잠재적인 변경. 현지화해야 합니다. 동기적으로 변경되는 요소는 근처에 있어야 합니다.

형식주의 2. 필요한 자체 테스트 기준.

SRP를 이행하기 위한 충분한 기준을 찾지 못했습니다. 그러나 필요한 조건이 있습니다:

1) 이 클래스/메서드/모듈/서비스가 무엇을 하는지 스스로에게 물어보세요. 간단한 정의로 대답해야 합니다. ( 감사합니다 브라이토리 )

설명

그러나 때로는 간단한 정의를 찾는 것이 매우 어렵습니다.

2) 버그를 수정하거나 새로운 기능을 추가하면 최소 파일/클래스 수가 영향을 받습니다. 이상적으로는 하나입니다.

설명

기능이나 버그에 대한 책임이 하나의 파일/클래스에 캡슐화되어 있으므로 어디를 보고 무엇을 편집해야 하는지 정확히 알 수 있습니다. 예를 들어, 로깅 작업의 출력을 변경하는 기능은 로거만 변경하면 됩니다. 나머지 코드를 실행할 필요는 없습니다.

또 다른 예는 이전 것과 유사한 새로운 UI 컨트롤을 추가하는 것입니다. 이로 인해 10개의 서로 다른 엔터티와 15개의 서로 다른 변환기를 추가해야 한다면 너무 과도하게 사용하는 것처럼 보입니다.

3) 여러 개발자가 프로젝트의 서로 다른 기능을 작업하는 경우 병합 충돌 가능성, 즉 여러 개발자가 동일한 파일/클래스를 동시에 변경할 가능성은 최소화됩니다.

설명

새로운 작업 "테이블 아래에 보드카 붓기"를 추가할 때 로거, 마시고 붓는 작업에 영향을 주어야 한다면 책임이 삐뚤게 나누어져 있는 것처럼 보입니다. 물론 이것이 항상 가능한 것은 아니지만, 이 수치를 줄이도록 노력해야 합니다.

4) 개발자나 관리자로부터 비즈니스 로직에 대한 명확한 질문을 받으면 엄격하게 하나의 클래스/파일로 이동하여 거기에서만 정보를 받습니다.

설명

기능, 규칙 또는 알고리즘은 각각 한 곳에 간결하게 작성되며 코드 공간 전체에 플래그와 함께 흩어져 있지 않습니다.

5) 이름이 명확합니다.

설명

우리 클래스나 메서드는 한 가지 일을 담당하며, 그 책임은 이름에 반영됩니다.

AllManagersManagerService - God 클래스일 가능성이 높습니다.
LocalPayment - 아마도 아닐 것입니다.

형식주의 3. Occam 우선 개발 방법론.

디자인 초기에 원숭이 남자는 문제가 해결되는 모든 미묘함을 모르고 느끼지 못하여 실수를 할 수 있습니다. 다양한 방법으로 실수를 할 수 있습니다:

• 서로 다른 책임을 병합하여 객체를 너무 크게 만듭니다.
• 하나의 책임을 다양한 유형으로 나누어 재구성
• 책임의 경계를 잘못 정의함

“큰 실수를 하는 것이 낫다”, “잘 모르겠으면 쪼개지 말라”는 규칙을 기억하는 것이 중요하다. 예를 들어 클래스에 두 가지 책임이 있는 경우에도 여전히 이해할 수 있으며 클라이언트 코드를 최소한으로 변경하여 두 개로 나눌 수 있습니다. 유리 조각으로 유리를 조립하는 것은 일반적으로 컨텍스트가 여러 파일에 분산되어 있고 클라이언트 코드에 필요한 종속성이 부족하기 때문에 더 어렵습니다.

이제 하루라고 할 시간이야

SRP의 범위는 OOP와 SOLID에만 국한되지 않습니다. 이는 메서드, 함수, 클래스, 모듈, 마이크로서비스 및 서비스에 적용됩니다. 이는 "figax-figax-and-prod" 및 "로켓 과학" 개발 모두에 적용되어 모든 곳에서 세상을 조금 더 좋게 만듭니다. 생각해보면 이것이 거의 모든 공학의 기본 원리이다. 기계 엔지니어링, 제어 시스템 및 실제로 모든 복잡한 시스템은 구성 요소로 구축되며 "과소 단편화"는 설계자의 유연성을 박탈하고 "과도한 단편화"는 설계자의 효율성을 박탈하며 잘못된 경계는 이성과 마음의 평화를 박탈합니다.

SRP는 자연적으로 발명된 것이 아니며 정확한 과학의 일부도 아닙니다. 그것은 우리의 생물학적, 심리적 한계를 뛰어넘는 것이며, 유인원의 뇌를 이용하여 복잡한 시스템을 제어하고 발전시키는 방법일 뿐입니다. 그는 시스템을 분해하는 방법을 알려줍니다. 원래 공식에는 상당한 양의 텔레파시가 필요했지만 이 기사를 통해 연막이 어느 정도 해소되었으면 좋겠습니다.

출처 : habr.com