Question

Lately I’ve been tinkering with TDD and coding based on the SOLID principles . I have a scenario as follows:

• One can have IRecurringProfile, which performs a series of payments on an interval, e.g monthly basis
• When a payment tries to go through and it fails, a IRecurringProfileTransaction is created linked to the IRecurringProfilePayment to show that the payment did not go through.
• The failure count for the payment is incremented.
• The date/time for which to retry payment and send another failure notification (if payment is failed) is also updated.
• If the failure count for a payment reaches a maximum threshold (e.g 3 failed attempts), the IRecurringProfile is suspended.
• Also, with each failure, a notification is sent to inform the client that the payment did not go through, and will be retried again.

Below is some sample code I created, which mainly deals with the task of marking a recurring profile payment as failed. I tried to follow on the SOLID principles, as well as constructor injection. Would like to know if this is violating any of these principles or any programming best-practices, and subject the code to any form of scrutiny so that it can be improved. The code also uses NHibernate as the ORM.

public class RecurringPaymentMarkAsFailure
{
    private readonly IPaymentFailedNotificationSender paymentFailedNotificationSender;
    private readonly IRecurringProfileFailureNextNotificationDateUpdater failureNotificationDateUpdater;
    private readonly IRecurringProfileSuspender recurringProfileSuspender;

    public RecurringPaymentMarkAsFailure(IPaymentFailedNotificationSender paymentFailedNotificationSender, IRecurringProfileSuspender recurringProfileSuspender,
        IRecurringProfileFailureNextNotificationDateUpdater failureNotificationDateUpdater)
    {
        this.paymentFailedNotificationSender = paymentFailedNotificationSender;
        this.failureNotificationDateUpdater = failureNotificationDateUpdater;

        this.recurringProfileSuspender = recurringProfileSuspender;

    }

    private void checkProfileStatus(IRecurringProfile profile)
    {
        if (profile.Status != Enums.RecurringProfileStatus.Active)
        {
            throw new Exceptions.RecurringProfileException("This cannot be called when the profile is not marked as active");
        }
    }


    private void incrementFailureCount(IRecurringProfilePayment payment)
    {
        payment.FailureCount++;
    }

    public IRecurringProfileTransaction MarkPaymentAsFailed(IRecurringProfilePayment payment, string failureData)
    {
        using (var t = BeginTransaction())
        {
            checkProfileStatus(payment.RecurringProfile);


            IRecurringProfileTransaction transaction = payment.Transactions.CreateNewItem();
            transaction.OtherData = failureData;
            transaction.Status = Enums.RecurringProfileTransactionStatus.Failure;
            paymentFailedNotificationSender.CreateAndQueueNotification(transaction);
            failureNotificationDateUpdater.UpdateNextFailureNotificationDate(payment);
            incrementFailureCount(payment);

            if (payment.FailureCount >= payment.RecurringProfile.MaximumFailedAttempts)
            {
                recurringProfileSuspender.SuspendRecurringProfile(payment.RecurringProfile);
            }
            transaction.Save();
            t.Commit();
            return transaction;
        }

    }

}

—

As a side note, this question complements my most recent post about a similar topic.

Answer 1

As I see it, you are violating the Single Responsibility Principle, since your RecurringPaymentMarkAsFailure has two responsibilities. Besides the responsibility of makring the payment as a failure, it also adds the responsibility of managing the transaction (the using (BeginTransaction); that is a cross-cutting concern.

You will probably have many classes like these in the system that handle business logic, and probably all (or many) have this exact same transaction code. Instead, consider adhering to the Open/Closed Principle by allowing to add this behavior as decorator. This is well possible, because the transaction is the first AND last operation in this code. A naive implementation of this decorator could look like this:

public class TransactionRecurringPaymentMarkAsFailureDecorator
    : RecurringPaymentMarkAsFailure
{
    private RecurringPaymentMarkAsFailure decoratedInstance;

    public RecurringPaymentMarkAsFailure(
        RecurringPaymentMarkAsFailure decoratedInstance)
    {
        this.decoratedInstance = decoratedInstance;
    }

    public override IRecurringProfileTransaction MarkPaymentAsFailed(
        IRecurringProfilePayment payment, string failureData)
    {
        using (var t = BeginTransaction())
        {
            var transaction = this.decoratedInstance
                .MarkPaymentAsFailed(payment, failureData);

            t.Commit();

            return transaction;
        }
    }
}

This decorator allows you to wrap the class as follows:

var marker =
    new TransactionRecurringPaymentMarkAsFailureDecorator(
        new RecurringPaymentMarkAsFailure(
            /* dependencies */    
        ));

As I said this implementation is a bit naive, since you will probably have many classes that need to be wrapped, and this means that each class would get its own decorator. Although this is completely SOLID, it isn’t DRY.

Instead, let all classes that execute use cases implement a single generic interface, something like ICommandHandler<TCommand>. This allows you to create a single generic TransactionCommandHandlerDecorator<TCommand> class to wrap all those instances. Take a look at this article to learn more about this model: Meanwhile… on the command side of my architecture.