facade design pattern

Question

Lately I've been trying to follow the TDD methodology, and this results in lot of subclasses so that one can easily mock dependencies, etc.

For example, I could have say a RecurringProfile which in turn has methods / operations which can be applied to it like MarkAsCancel, RenewProfile, MarkAsExpired, etc.. Due to TDD, these are implemented as 'small' classes, like MarkAsCancelService, etc.

Does it make sense to create a 'facade' (singleton) for the various methods/operations which can be performed on say a RecurringProfile, for example having a class RecurringProfileFacade. This would then contain methods, which delegate code to the actual sub-classes, eg.:

public class RecurringProfileFacade
{
    public void MarkAsCancelled(IRecurringProfile profile)
    {
        MarkAsCancelledService service = new MarkAsCancelledService();
        service.MarkAsCancelled(profile);
    }
    public void RenewProfile(IRecurringProfile profile)
    {
        RenewProfileService service = new RenewProfileService();
        service.Renew(profile);
    }
    ...
}

Note that the above code is not actual code, and the actual code would use constructor-injected dependencies. The idea behind this is that the consumer of such code would not need to know the inner details about which classes/sub-classes they need to call, but just access the respective 'Facade'.

First of all, is this the 'Facade' pattern, or is it some other form of design pattern?

The other question which would follow if the above makes sense is - would you do unit-tests on such methods, considering that they do not have any particular business logic function?

Answer 1

I would only create a facade like this if you intend to expose your code to others as a library. You can create a facade which is the interface everyone else uses.

This will give you some capability later to change the implementation.

If this is not the case, then what purpose does this facade provide? If a piece of code wants to call one method on the facade, it will have a dependency on the entire facade. Best to keep dependencies small, and so calling code would be better with a dependency on MarkAsCancelledService tha one on RecurringProfileFacade.