大フロントエンド昇格シリーズの-単一職責原則

The Single Responsibility Principle(単一職責SRP)
開発者がインタフェースを設計するときに、ユーザーのプロパティやユーザーの動作がインタフェースに宣言されるなどの問題がある場合があります.これにより、ビジネスオブジェクトとビジネスロジックが一緒に置かれ、このようにして、このインタフェースには2つの職責があり、インタフェースの職責が明確ではなく、SRPの定義に従ってインタフェースの単一職責の原則に背いている.
文字通り単一職責の原則を理解するのは、機能が単一であることですか?

A class should have only one reason to change

単一の職責とは、1つの設計要素が1つのことしかしないことです.「一つだけやる」とは何ですか.簡単に言えば余計なことはしないでください.現実にはそうです.もしあなたが一つのことに専念しなければならないなら、誰もが素晴らしいことをする自信があります.しかし、もしあなたが一日中めちゃくちゃなことに疲れていたら、すべてのことをする気と精力がありますか?
 
なぜ職責を分離する必要があるのですか?
私たちが日常的に機能を開発していることを考えてみてください.どんな論理をクラスに書くのが好きですか.アルゴリズム、UI構造、レンダリング、データベース操作などです.もちろん、これはもともと個別の機能ブロックだと言います.はい、そうです.しかし、似たような機能ブロックを開発するには、もう一度書き直す必要がありますか.多重化は基本的に不可能になる.この場合、変更があれば、2つの機能ブロックの類似コードを同時に変更する必要があります.ここでは抽象コードの多重化と分類後、各クラスに独自の職責があることを強調します.
 
職責をどのように分離しますか?
これも一番難しいところだと思います.機能設計の中で、私は合理的ではないことを知っているかもしれませんが、職責をどのように分離するか分かりません.
jQueryを見てみましょう
jQueryのAPI仕様は比較的合理的で,css(),attr(),ajax(),animate()を見ることができ,各インタフェースに対応する機能職責は単一であり,これは機能抽象の観点からである.
細分化するとcssはsetとgetを区別するので、職責とは異なるようですが、jQueryという逆モード設計は開発者に人気があります
しかし、自分の機能ブロックにsetクラスを書き込み、set(‘css’)、set(‘sttr’)、set(‘animate’)を渡すことで、問題が明らかになります.
1つのsetクラスが担う職責が多すぎて、cssを操作することができて、attrを操作することができて、アニメーションを操作することができて、setクラスはすべての機能を1つのモジュールの中に書いて、これらの職責を結合することに等しいです
1つの職責の変化は、このクラスが他の職責を遂行する能力を弱めたり抑制したりします.この結合の設計は脆弱で、問題が発生する確率も増加します.
分離の原則は
複数の動機を考えてこのクラスを変えることができれば,このクラスには具体的に1つ以上の職責があり,分離を考慮することができる.
 
では、単一職責の原則の意味は何なのか.

クラスの複雑さを低減し、どのような職責を実現するかを明確に定義する

可読性向上

保守性向上

変更によるリスクを低減し、システムの拡張性とメンテナンス性に役立ちます.
しかし、単一職責の原則を用いることには問題があり、「職責」には明確な区分基準がなく、職責を細かく区分するとインタフェースや実装クラスの数が急増し、かえって複雑度が向上し、コードのメンテナンス性が低下する.だから、この職責を使うときは、具体的な状況を具体的に分析しなければなりません.提案はインタフェースが必ず単一職責原則を採用し、クラスの設計を実現する上でできるだけ単一職責原則を実現し、一つの原因が一つのクラスの変化を引き起こすことが望ましい.