0

私は最近このSingle Responsibility Principle概念を読んでいますが、理論的にはそれに非常に同意します。私は、コードが原則に違反していると正確に分類できる用語を理解するのに苦労しています。テスト駆動開発に向けて、この原則を実装したいと思います。

たとえば、以下のコードを見てください。

public void MarkAsSuccessful(PaymentMethodSpecific paymentMethod, bool requiresManualIntervention)
    {
            this.Paid = true;
            this.PaidOn = CS.General_v3.Util.Date.Now;
            this.PaidByPaymentMethod = paymentMethod;
            this.RequiresManualIntervention = requiresManualIntervention;

            this.Update();

        this.CreateAndSendNotificationRegardingImmediatePayment();

        this.SendPaymentSuccessfulEmails();

    }

PaymentRequestこれは、基本的にeコマースアプリケーションでの支払いに関連するロジックを処理するクラスである、と呼ばれるクラスに配置されます。上記のメソッドは、リクエストを「成功」としてマークします。これは、支払われた列とその他の情報をマークし、これが成功したという通知を送信し、電子メールを送信する必要があります。

たとえば、単体テストの場合、通知が実際に作成されて送信されたことや、支払いメールが送信されたことを知る方法がないため、この方法を単体テストすることは非常に困難です。SRPコンセプトの経験豊富な人々がそのような例にどのようにアプローチするか知りたいです。

4

1 に答える 1

1

私の推測では、PaymentProcessorクラスがマージされているか、クラスに埋め込まれていると思いますPaymentRequest。

PaymentProcessorPaymentRequest基本的には、通過する有限状態マシンです。

これPaymentProcessorを作成するときは、「即時支払い通知」と一般的な電子メールを処理するオブジェクトを挿入します。このようにして、予想される条件が発生したことを表明するモックオブジェクトを挿入することにより、すべての状態を個別にテストし、プロセッサをテストします。

単一責任自体は素晴らしい概念ですが、SOLID全体に投資し始めると、その力は本当に生まれます。

于 2012-08-23T16:42:16.413 に答える