5

私は実際の責任とは何かを理解しようとしているので、現在取り組んでいることの例を使用したいと思います。あるシステムから別のシステムに製品情報をインポートするアプリがあります。アプリのユーザーは、一方のシステムの製品フィールドでもう一方のシステムで使用するさまざまな設定を選択できます。

だから私にはProductImporterというクラスがあり、その責任は製品をインポートすることです。このクラスは大きいですが、おそらく大きすぎます。

このクラスのメソッドは複雑で、たとえばgetDescriptionになります。この方法は、単に他のシステムから説明を取得するのではなく、ユーザーが設定したさまざまな設定に基づいて製品の説明を設定します。説明を取得するための設定と新しい方法を追加すると、このクラスが変更される可能性があります。

それで、それは2つの責任ですか?製品を輸入するものと説明を得るものはありますか?私が持っているほとんどすべてのメソッドはそれ自身のクラスにあり、それはやり過ぎのように思えます。

完全に理解するのは難しいので、この原則をよく説明する必要があります。不必要な複雑さは望んでいません。

4

1 に答える 1

3

この原則では、「責任」は変更の理由として定義されています。この場合、クラスの唯一の責任は製品をインポートすることです。商品の輸入方法が変われば、クラスも変わるはずです。

その意図は、異なるものが同じクラスを同時に変更することを避けることです。たとえば、製品のインポーター クラスで出力形式も定義されている場合、出力形式はデータをインポートするメカニズムとはまったく関係がない可能性が高いため、2 つの責任があります。

さて、クラスが巨大で、getDescription() も説明を設定することは、SRP の直接の違反ではなく、異なる原則の違反です。つまり、巨大なクラスを持つことは避けるべきであり (設計の欠如を示しています)、各メソッドは単一のことを行う必要があります (これは、SRP のより具体的なバージョンのようなものです)。

于 2010-02-19T15:13:24.437 に答える