SRP - 各クラスは 1 つの責任 (つまり、変更の理由) を持つべき
です。懸念事項は、プログラムにおける関心または焦点の一部です。(懸念 == システムの特徴。)
a）私の理解では、2つの唯一の違いは、SRPが責任を異なるクラスに分離しようとし、SoCが懸念を異なるモジュールに分離しようとすることです?!
b) a ) の仮定が正しい場合、懸念と責任の違いは何ですか (責任がより低い抽象レベルに存在するという事実以外に)?
ありがとうございました
2 に答える
1
それが私がそれらをどのように見ているかです - 同じ原則であり、通常は異なる抽象化レベルで参照されます.
于 2012-10-15T01:43:41.803 に答える
1
良い質問です。:) 免責事項: あくまで私の考えです。区別は今まで考えたことがありませんでした。2 つの概念に大きな違いはないと思います。
しかし、ここで私が言いたいのは、横断的な懸念についてしか知らないということです。懸念の基本的な考え方は、あなたが言うように、プログラムにおける関心または焦点の一部ですが、横断的でない場合、懸念は責任になりますか?
原理は同じだと思います。そして、私の理解でさえあなたの理解と同じです。ショッピング カート システムでは、カートにアイテムを追加することは懸念事項と見なすことができます...ユース ケースが行うべき主な事柄です。関連するクラスは、ロギングやセキュリティなどについてはあまり考慮していません。ロギングがなくても、項目をクラスに追加できます。しかし、カートまたはサービスがアイテムを追加する機能を公開する必要がある場合、ユース ケースは失敗します。同様に、ロギング ユース ケースの場合、ロガーがアクティビティのロギングに失敗した場合、アイテムがカートに追加されたとしても、ロギング ユース ケースが機能していないことを意味します。
カートにアイテムを追加するのは誰の責任ですか? (CartService としましょう) AddItemToCart ストーリーが失敗した場合、それは責任を負いますか? はい。LogAddItemActivity が失敗した場合、責任は問われますか? いいえ。AddItemToCart のストーリーはログ記録に関係していますか。です。CartService が担当するアクティビティから分離できますか? モジュールとクラスは、さまざまなレベルの抽象化です。
于 2012-10-15T09:37:58.807 に答える