単一責任の原則。 見た目ほど単純ではありません

単一責任の原則、単一責任の原則とも呼ばれます。
別名均一変動性の原理 - 理解するのが非常に難しく、プログラマーの面接では非常に緊張する質問です。

私がこの原理を初めて真剣に知ったのは、XNUMX年生の初め、幼虫から生徒、つまり本物の生徒を作るために若くて緑色の子が森に連れて行かれたときでした。

森の中で、私たちは8～9人のグループに分かれて、グループの最初の人がグラスにウォッカを注ぎ、XNUMX番目の人がそれを飲むという条件で、どのグループがウォッカのボトルを一番早く飲むか競争しました。そしてXNUMX人目はおやつを食べます。 操作を完了したユニットはグループのキューの最後に移動します。

キュー サイズが XNUMX の倍数であるケースは、SRP の適切な実装でした。

定義 1. 単一の責任。

単一責任原則 (SRP) の公式の定義では、各エンティティは独自の責任と存在理由を持ち、責任は XNUMX つだけであると述べられています。

オブジェクト「酒飲み」(チッププラー).
SRP 原則を実装するために、私たちは責任を XNUMX つに分割します。

• XNUMX つを注ぎます (注ぐ操作)
• 一杯飲みます（ドリンクアップオペレーション)
• 一人は軽食を持っています（テイクバイトオペレーション)

プロセスの各参加者は、プロセスの XNUMX つのコンポーネントに対して責任を負います。つまり、飲む、注ぐ、軽食という XNUMX つの原子的な責任を負います。

水飲み場は、次のような操作のファサードです。

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

なぜですか？

人間のプログラマーは猿人のためにコードを書きますが、猿人は不注意で愚かで、いつも急いでいます。 彼は一度に約 3 ～ 7 つの用語を保持して理解することができます。
酔っぱらいの場合には、これらの用語が XNUMX つあります。 しかし、コードを XNUMX 枚のシートで作成すると、手、メガネ、喧嘩、政治に関する終わりのない議論が含まれることになります。 これらすべてが XNUMX つのメソッドの本体に含まれます。 あなたも実務でそのようなコードを見たことがあると思います。 精神にとって最も人道的なテストとは言えません。

一方、猿人は頭の中で現実世界の物体をシミュレートするように設計されています。 彼の想像力の中で、それらを押し合わせたり、そこから新しいオブジェクトを組み立てたり、同じ方法で分解したりすることができます。 古いモデルの車を想像してください。 想像力の中で、ドアを開け、ドアトリムを緩めると、窓の昇降機構があり、その中に歯車が入っているのが見えます。 ただし、マシンのすべてのコンポーネントを XNUMX つの「リスト」で同時に確認することはできません。 少なくとも「猿人」には無理だ。

したがって、人間のプログラマは、複雑なメカニズムをそれほど複雑ではない機能する要素のセットに分解します。 ただし、分解方法はさまざまです。多くの古い車では、エアダクトがドアに入り込み、現代の車では、ロック電子機器の故障によりエンジンが始動できなくなり、修理中に問題が発生する可能性があります。

今、 SRPはどのように分解するか、つまりどこに境界線を引くかを説明する原則です.

彼は、「責任」の分割の原則に従って、つまり特定のオブジェクトのタスクに従って分解する必要があると述べています。

飲酒と分解中に猿人が受ける利点に戻りましょう。

• コードはあらゆるレベルで非常に明確になりました
• コードは複数のプログラマーが同時に作成できます (各プログラマーが個別の要素を書き込みます)。
• 自動テストは簡素化されます - 要素が単純であればあるほど、テストが簡単になります。
• コードの構成性が表示されます - 置き換えることができます ドリンクアップオペレーション 酔っぱらいがテーブルの下に液体を注ぐという行為。 または、注ぐ操作を、ワインと水、またはウォッカとビールを混ぜる操作に置き換えます。 ビジネス要件に応じて、メソッド コードに触れることなくすべてを実行できます ティップラー・アクト.
• これらの操作により、グルトンを折りたたむことができます（のみを使用します） TakeBitオペレーション）、アルコール（のみ使用） ドリンクアップオペレーション ボトルから直接）、その他多くのビジネス要件を満たします。

(ああ、これはすでに OCP の原則のようで、この投稿の責任に違反しました)

そしてもちろん、短所もあります:

• さらに多くのタイプを作成する必要があります。
• 酔っ払いは、通常よりも数時間遅れて初めてお酒を飲みます。

定義 2. 統一された変動性。

許してください、紳士諸君！ 飲酒クラスにも責任は XNUMX つあります。それは飲むことです。 そして一般に、「責任」という言葉は非常に曖昧な概念です。 人類の運命には誰かが責任を負い、極地でひっくり返ったペンギンを育てる責任も誰かにある。

ドリンカーの XNUMX つの実装を考えてみましょう。 上で説明した最初のクラスには、注ぐ、ドリンク、スナックの XNUMX つのクラスが含まれています。

XNUMX つ目は、「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は次のよ​​うに述べています。モジュールを変更する理由はただ XNUMX つだけです」。 それは、「責任は変化の理由である」ということです。

（元々の定義を考えた人たちは猿人のテレパシー能力に自信があったようです）

これで、すべてがうまくいきました。 注ぐ、飲む、おやつの手順を個別に変更できますが、ドリンカー自体では、たとえば飲む前におやつを移動したり、乾杯の読みを追加したりするなど、操作の順序と構成を変更することしかできません。

「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)
        }
    }
}

注意深く読んでいる方ならお気づきでしょうが、 ログアフター, 前のログ и エラー時 個別に変更することもでき、前の手順と同様に、次の XNUMX つのクラスが作成されます。 注ぐロガー前, 注ぐロガー後 и PourErrorLogger.

そして、飲酒者には 14 つの操作があることを思い出して、XNUMX つのロギング クラスを取得します。 結果、飲み会サークル全体はXNUMXクラス（!!!）となりました。

双曲線？ しそうにない！ 分解手榴弾を持った猿人は、「注ぐ人」をデカンタ、グラス、注ぎオペレータ、給水サービス、分子衝突の物理モデルに分割し、次の四半期に渡って依存関係を解きほぐそうとします。グローバル変数。 そして信じてください、彼は止まらないでしょう。

この時点で、多くの人は SRP はピンクの王国のおとぎ話であるという結論に達し、ヌードルをするために去っていきます...

...Srp の XNUMX 番目の定義の存在について学習することなく、次のようになります。

「単一責任原則では次のように述べられています。 変更に類似したものは XNUMX か所に保管する必要があります」。 または "一緒に変更されるものは XNUMX か所に保管する必要があります　

つまり、操作のログを変更する場合は、XNUMX か所で変更する必要があります。

これは非常に重要な点です。上記の SRP のすべての説明では、型を潰すときに型を潰す必要がある、つまり、オブジェクトのサイズに「上限」を課す必要があると述べられていたため、すでに「下限」について話しています。 言い換えると、 SRPでは「潰しながら潰す」だけでなく、無理をしない「連動したものを潰さない」ことも求められます。。 オッカムのカミソリと猿人の大決戦だ！

これで、飲酒者は気分が良くなるはずです。 IPourLogger ロガーを XNUMX つのクラスに分割する必要がないことに加えて、すべてのロガーを XNUMX つのタイプに結合することもできます。

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

XNUMX 番目のタイプの操作を追加すると、そのログの準備はすでに完了しています。 また、操作のコード自体はクリーンで、インフラストラクチャのノイズがありません。

その結果、飲酒問題を解決するための 5 つのクラスが用意されました。

• 注湯作業
• 飲酒運転
• ジャミング操作
• ロガー
• 酒飲みのファサード

それぞれが XNUMX つの機能を厳密に担当しており、変更の理由は XNUMX つあります。 変更に似たルールはすべて近くにあります。

実際の例

私たちはかつて、B2B クライアントを自動的に登録するサービスを作成しました。 そして、同様の内容の 200 行に対して GOD メソッドが登場しました。

• 1Cに移動してアカウントを作成します
• このアカウントを使用して、支払いモジュールに移動し、そこで作成します
• メインサーバーにそのようなアカウントが作成されていないことを確認してください
• 新しいアカウントを作成する
• 支払いモジュールの登録結果と 1c 番号を登録結果サービスに追加します
• このテーブルにアカウント情報を追加します
• ポイント サービスでこのクライアントのポイント番号を作成します。 1c アカウント番号をこのサービスに渡します。

そして、このリストには、接続がひどい状態にある事業所がさらに 10 件ほどありました。 ほぼ全員がアカウント オブジェクトを必要としていました。 コールの半分でポイント ID とクライアント名が必要でした。

100 時間のリファクタリングの後、インフラストラクチャ コードとアカウント操作の微妙な部分を個別のメソッド/クラスに分離することができました。 God メソッドのおかげで作業は簡単になりましたが、解きほぐしたくないコードが XNUMX 行残っていました。

この「軽量」手法の本質がビジネス アルゴリズムであることが明らかになったのは、数日後でした。 そして、技術仕様の元の説明は非常に複雑でした。 そして、このメソッドを細かく分割しようとする試みが SRP に違反することになり、その逆はありません。

形式主義。

酔っぱらいを放っておく時が来た。 涙を拭いてください - いつか必ず戻ってきます。 それでは、この記事の知識を形式的に整理してみましょう。

形式主義 1. SRP の定義

1. それぞれの要素が XNUMX つのことを担当するように要素を分離します。
2. 責任とは「変化する理由」を意味します。 つまり、ビジネス ロジックの観点から、各要素の変更理由は XNUMX つだけです。
3. ビジネス ロジックが変更される可能性があります。 ローカライズする必要があります。 同期的に変化する要素は近くにある必要があります。

形式主義 2. 必要な自己テスト基準。

SRPを満たすための十分な基準がわかりません。 ただし、必要な条件があります。

1) このクラス/メソッド/モジュール/サービスが何をするのかを自問してください。 簡単な定義で答えなければなりません。 （ ありがとう ブライトリ )

説明

ただし、単純な定義を見つけるのが非常に難しい場合があります。

2) バグの修正または新しい機能の追加は、ファイル/クラスの最小数に影響します。 理想的には - XNUMX つ。

説明

(機能またはバグに対する) 責任は XNUMX つのファイル/クラスにカプセル化されているため、どこを調べて何を編集すればよいかが正確にわかります。 たとえば、ロギング操作の出力を変更する機能では、ロガーのみを変更する必要があります。 残りのコードを実行する必要はありません。

別の例は、以前のものと同様の新しい UI コントロールを追加することです。 これにより、10 の異なるエンティティと 15 の異なるコンバータを追加する必要がある場合は、やりすぎのように見えます。

3) 複数の開発者がプロ​​ジェクトの異なる機能に取り組んでいる場合、マージ競合の可能性、つまり同じファイル/クラスが複数の開発者によって同時に変更される可能性は最小限になります。

説明

「テーブルの下にウォッカを注ぐ」という新しい操作を追加するときに、飲む操作と注ぐ操作であるロガーに影響を与える必要がある場合、責任が歪んで分割されているように見えます。 もちろん、これが常に可能であるとは限りませんが、この数字を減らすように努める必要があります。

4) ビジネス ロジックについて (開発者またはマネージャーから) 明確な質問をされた場合、厳密に XNUMX つのクラス/ファイルにアクセスし、そこからのみ情報を受け取ります。

説明

機能、ルール、アルゴリズムはそれぞれ XNUMX か所にコンパクトに記述され、コード空間全体にフラグが散らばることはありません。

5) ネーミングがわかりやすい。

説明

私たちのクラスまたはメソッドは XNUMX つのことに対して責任を負い、その責任はその名前に反映されています。

AllManagersManagerService - おそらく神クラス
LocalPayment - おそらくそうではありません

形式主義 3. オッカムファーストの開発方法論。

設計の開始時には、サルマンは解決されている問題のすべての微妙な点を理解しておらず、感じていないため、間違いを犯す可能性があります。 さまざまな方法で間違いを犯す可能性があります。

• さまざまな責任を統合してオブジェクトが大きくなりすぎる
• XNUMX つの責任をさまざまな種類に分割して再構成する
• 責任の範囲を誤って定義する

「大きな間違いをしたほうが良い」「確信が持てない場合は分割しない」というルールを覚えておくことが重要です。 たとえば、クラスに XNUMX つの責任が含まれている場合でも、それは理解可能であり、クライアント コードへの最小限の変更で XNUMX つに分割できます。 ガラスの破片からガラスを組み立てるのは、コンテキストが複数のファイルに分散していたり​​、クライアント コードに必要な依存関係がなかったりするため、通常はより困難になります。

もう終わりにする時が来た

SRP の範囲は OOP と SOLID に限定されません。 これは、メソッド、関数、クラス、モジュール、マイクロサービス、およびサービスに適用されます。 これは「figax-figax-and-prod」開発と「ロケットサイエンス」開発の両方に適用され、あらゆる場所で世界を少しでも良くします。 考えてみれば、これはすべてのエンジニアリングのほぼ基本原則です。 機械工学、制御システム、そして実際すべての複雑なシステムはコンポーネントから構築されており、「断片化不足」は設計者の柔軟性を奪い、「断片化過剰」は設計者の効率を奪い、境界線が間違っていると理性と安心感を奪います。

SRP は自然に発明されたものではなく、精密科学の一部でもありません。 それは私たちの生物学的および心理的限界を打ち破り、猿人の脳を使って複雑なシステムを制御し開発する方法にすぎません。 彼はシステムを分解する方法を教えてくれます。 元の定式化にはかなりの量のテレパシーが必要でしたが、この記事で煙幕の一部が解消されることを願っています。

出所： habr.com