Clever Geek Handbook

唯一の責任の原則：分解の基礎



プログラミングに携わっている人なら誰でも、この原則について聞いたことがあります。 彼を知っていると思う人より少し少ない。 使い方を本当に知っている人よりもはるかに少ない。 この原則の本質、目的、および適用について、できるだけシンプルかつ簡潔に説明しようと思います。







定義



各プログラムオブジェクトには1つの目的しかありません。

アライアンスを使用せずに、1つの文で網羅的に説明できます。







例



Lazy <T>-最初の呼び出しまで作成が遅延するオブジェクトのラッパー。







反例



シングルトンは、複数のインスタンスの作成を許可しないクラスです。 この説明には共用体はありませんが、不完全です。シングルトンは、独自のインスタンスの一意性を制御することに加えて、常に基本的な機能を備えています。 シングルトンは、便利な機能を実装し、独自のインスタンスの一意性を制御するクラスです。 説明は包括的ですが、「and」の結合があります。シングルトンには2つの異なる目的があります。 それは、単独の責任の原則に準拠していません。







別の反例



Service Locator-任意のアプリケーションサービスにアクセスできます。 サービスの完全なリストのないこの説明は明らかに不完全です。







予定



ソフトウェアシステムの作成、分析、変更の簡素化。







分析



分析と評価は、「なぜこれが必要なのか？」という質問に対する答えを先験的に知っていることによって簡素化されています。

単一の責任を持つプログラムオブジェクトは、負荷が追加されたプログラムオブジェクトよりも意図的に単純で小さくなります。 それどころか、多くの責任を持つオブジェクトは、「なぜそれが作成されたのか」という質問に対する包括的な回答を許可しないことがよくあります。 私自身の著者にも。 唯一の責任の原則を適用することに対する従来の議論は、プロジェクト内の多数の小さなオブジェクトです。 少数の大規模なエンティティでは、アプリケーション全体の構造をナビゲートして理解する方が簡単であると思われます。







実際、オリエンテーションの容易さは、プロジェクト内のクラスの数ではなく、特定の各クラスと残りのクラスの接続の数に依存しません。 単独の責任の原則に従って設計されたアプリケーションの場合、この指標はより低いと予想されます。

そして、プロジェクト全体の理解を促進する最も効果的な方法は、アプリケーションのコンテキストで構成を担当する特別なオブジェクトを強調することです。







作成



再利用を簡素化することにより、既存のソフトウェアシステムの新規作成および拡張が容易になります。 構築を唯一の責任とするオブジェクトには、過剰な機能はありません。 その結果、プロジェクト全体のタスクを実装するために必要な場合もあれば、まったく実装しない場合もあります。 冗長機能を維持する必要はありません。 前の段落のコストが高いため、既存の実装を複製する必要はありません。







修正



変更のローカライズが改善されるため、既存の機能の変更は安価になります。 軽微な変更は、特定の責任までバージョン管理システムに表示されます。 多数の変更されたファイルがあるため、大きな変更はすぐに目立ちます。 単独の責任を持つ施設の単体テストは、コードに入力された欠陥に関する詳細情報を提供します。







禁忌



唯一の真の禁忌は、ソフトウェアシステムの開発および運用中のリソース消費の最適化です







開発



唯一の責任の原則を一貫して遵守する初期開発のコストは、より徹底的な分析と特定のタスク内のコード量の増加の必要性により高くなります。







プロジェクトが複雑になるほど、内部品質の要件が高くなり、コードの量が多くなります-単独責任の原則を無視する理由が少なくなります。







操作



低レベルの最適化を伴うコードは、多くの場合、単独の責任の原則に準拠できません。 時期尚早な最適化はすべての悪の根源であるため、最初に機能的に正しいバージョンを開発し、次にボトルネックを最適化することは論理的です。







難易度



原理自体は非常にシンプルで、曖昧さや弁証法はありません。アプリケーションの効果は明ら​​かで、非常に迅速に実を結びます。 しかし、責任を発見して強調するスキルは創造的であり、プログラマの能力に大きく依存し、経験と新しい方法論、技術、ツールの研究を通じて開発および訓練します。







たとえば、関数型プログラミングの研究により、OOPのみを使用して検出するのが非常に難しい責任に気付き、強調することができます。 原則を使用することの主な障害は、その直感に反することです。人間の脳は、すべての複雑な質問に対する唯一の「単純な」答えを探して見つける傾向があります。







ここから、アンチパターン「Divine Object」のルーツが成長します。 多くの人がシングルトンのアンチパターンをまだ考慮していないのはそのためです。 問題のもう1つの側面は、開発者が複雑なソリューションの形で課題を見つけて受け入れることです。 唯一の責任の原則により、複雑さが必要最小限に抑えられ、プログラマーの関心が減ります。 開発者の才能は、「常識」と野心のある直感が正反対を必要とする場合でも、問題に対する最もシンプルで最も効果的なソリューションを選択して実装する能力にあります。







まとめ



唯一の責任の原則を理解して適用することは、プログラマーの最も重要なスキルであり、絶えず開発され、訓練される必要があります;それなしでは、エンジニアは実行する技術者に変わり、せいぜい他の人のパターンで働きます。







.NETでのアプリケーション



  1. インターフェース-別の責任としての契約の割り当て。
  2. クラス-連絡先の実装を強調表示します。
  3. メソッド-アルゴリズムの選択。
  4. デリゲート-ポリ​​モーフィズムを強調します。


原則とパターンでの適用



  1. インターフェースの分離の原則は、契約の唯一の責任です
  2. 開放性の原則は、実装の唯一の責任です。
  3. 依存性注入-オブジェクトの構成を別個の責任として分離します。
  4. 工場-オブジェクト作成ハイライト
  5. ORM-データベース内のオブジェクトの表示の強調表示サポート


More articles:


All Articles