リリースされたプログラムがあるとします。顧客がやって来て、その機能の1つに対する拡張機能の代金を支払うことを提案します。お金を稼ぐためには、プログラムを変更して新しい機能を追加する必要があります。あなたの利益率が何であるかに影響を与えるもののいくつかは次のとおりです。
- 変更する必要があるコードの量
- 変更がどれほど簡単か
- 他の顧客が使用している既存の機能を壊す可能性
- 既存のモデル/アーキテクチャをどれだけ再利用できるか
懸念の分離は、これらの質問に対するより肯定的な答えを得るのに役立ちます。
- アプリケーションの特定の動作のコードがすべて分離されている場合は、新しい機能に直接関連付けられているコードを変更するだけで済みます。変更するコードを少なくする必要があります。
- 関心のある動作がアプリケーションの残りの部分からきちんと分離されている場合は、プログラムの残りの部分を完全に理解または操作する必要なく、新しい実装でスワップできる可能性が高くなります。また、変更が必要なコードを見つけやすくなります。
- 変更する必要のないコードは、変更するコードよりも破損する可能性が低くなります。したがって、懸念事項を分割することで、それらが呼び出す可能性のあるコードを変更する必要がなくなるため、無関係な機能の破損を回避できます。機能が混ざっている場合、別の機能を変更しようとしているときに、誤って機能の動作を変更する可能性があります。
- アーキテクチャが技術的またはビジネスロジックの詳細にとらわれない場合、実装の変更により新しいアーキテクチャ機能が必要になる可能性は低くなります。たとえば、メインドメインロジックがデータベースにとらわれない場合、新しいデータベースのサポートは、永続化レイヤーの新しい実装で交換するのと同じくらい簡単です。
病院を見て、看護師、医師、医療助手、技術者、事務スタッフ、食堂など、患者へのケアの提供に関連するさまざまな役割をすべて考えます。
allの方法を知っている人がいますか？いいえ、圧倒されるからです。彼らは異なる責任を異なる役割に分けなければならず、それらの役割の間のタッチポイントは非常に具体的です。
もし彼/彼女がオフィスで働いているなら、それを例に取って、そのオフィスでの各スタッフの役割を説明し、そして彼らに彼らの仕事に応じてそれらのスタッフが分けられていなかったらどうなるでしょうか？
私は彼がどのようにコード/デザインにSoCを適用できなかったかを調べ、それを彼が関係することができる実際の例に変え、それは明らかに望ましくありません。
たとえば、彼がクライアントに関連のないいくつかの情報を提供する必要があるクラスがある場合、私はあなたが購入したい場合は自分の穀物と酵母を持参しなければならないパン屋のアナロジーを使用しますパン。