4

オブジェクトを「単一の責任」に分解する場合、同様のオブジェクトが一緒に存在するか、個別に存在するかについての基本的な考えはありますか?たとえば、私が持っている場合

class Employee_DataProvider() : IEmployee_DataProvider { ... };
class Employee_Details() : IEmployee_Details { ... };
class Employee_Payroll() : IPayroll() { ... };
class Employee_LeaveProcessing() : ILeaveProcessing_Client { ... };
...

これらすべてが内部に存在し、インターフェースを介して疎結合されているのは悪臭ですか?所有する Employee クラス:

class Employee
{
    IEmployee_DataProvider _dataProvider;
    IEmployee_Details _details;
    IPayroll _payroll;
    ILeaveProcessing_Client _leaveProcessing;

    //My functions call the interfaces above

}

それとも、コード内でこれらのクラスを完全に分離する (または少なくとも可能な限り分離する) ことを中心に考えていますか? それとも、これらの方法は両方とも SRP の有効な使用法ですか?

編集:例で与えられたオブジェクトの実現可能性について批判したくありません。質問を説明するために作成しただけです。データ、休暇、給与処理は従業員クラスのドメインではないことに同意します。

ただし、SRP は、現実世界の表現としてのオブジェクトから離れて、単一の機能概念に関するプロパティおよびメソッドとしてのオブジェクトに移動するように私に求めているようです。

4

2 に答える 2

4

OOP の基本に戻りましょう。Employee オブジェクトには、何を行うかではなく、何を行うかを反映するメソッドが必要です。

于 2009-01-17T02:41:42.110 に答える
2

原則自体に関する私の実際の質問にはまだ誰も答えていませんが、私が示したやや貧弱な例ではなく、質問に明らかに興味がある人のために、それに影響を与えるプロセスについてあまりにも多くのことを知っているEmployeeオブジェクトについてです（2つあります） 「お気に入り」の星）私はもっと多くの議論を望んでいましたが、もう少し読みました。

現在の2つの答えが言おうとしているのは、分離された責任は独立できるはずであり、私の例はすべきでないことの完璧な例だったと思います。私はそれを受け入れてとても幸せです。

ObjectMentor （Uncle Bobのサイト）からの段落があり、 ConnectionオブジェクトとDataReaderオブジェクト（以前はモデムクラスに存在していたが分離された2つのオブジェクト）をModemImplementationに結合する例がありますが、次のように述べています。

ただし、2つの責任を1つのModemImplementationクラスに再結合したことに注意してください。これは望ましくありませんが、必要な場合があります。多くの場合、ハードウェアまたはOSの詳細に関係して、結合したくないものを結合することを余儀なくされる理由があります。ただし、それらのインターフェースを分離することにより、アプリケーションの残りの部分に関する限り、概念を切り離しました。

ModemImplementationクラスは、応急修理または疣贅であると見なす場合があります。ただし、すべての依存関係がそこから流れ出ることに注意してください。誰もこのクラスに依存する必要はありません。メイン以外の誰もそれが存在することを知る必要はありません。したがって、私たちは醜いビットをフェンスの後ろに置きました。醜いことは、アプリケーションの残りの部分を漏らして汚染する必要はありません。

ここでは、「すべての依存関係がそこから流れ出ることに注意してください」という行が重要だと思います。

于 2009-01-17T06:52:54.457 に答える