Is it a leaky abstraction if implementation of int

Question

Consider this code:

public class MyClass()
{
  public MyClass()
  {    
  }

  public DoSomething()
  {
    using (var service = new CustomerCreditServiceClient())
    {
       var creditLimit = service.GetCreditLimit(
         customer.Firstname, customer.Surname, customer.DateOfBirth);       
    }
  }
}

We now want to refactor it to loosely couple it. We end up with this:

public class MyClass()
{
  private readonly ICustomerCreditService service;

  public MyClass(ICustomerCreditService service)
  {
     this.service= service;
  }

  public DoSomething()
  {
     var creditLimit = service.GetCreditLimit(
       customer.Firstname, customer.Surname, customer.DateOfBirth);       
  }
}

Looks ok right? Now any implementation can use the interface and all is good.

What if I now say that the implementation is a WCF class and that the using statement before the refactoring was done was there for a reason. ie/to close the WCF connection.

So now our interface has to implement a Dispose method call or we use a factory interface to get the implementation and put a using statement around that.

To me (although new to the subject) this seems like a leaky abstraction. We are having to put method calls in our code just for the sake of the way the implementation is handling stuff.

Could someone help me understand this and confirm whether I'm right or wrong.

Thanks

Answer 1

Yes, it is a leaky abstraction when you let ICustomerCreditService implement IDisposable, since you've now written ICustomerCreditService with a specific implementation in mind. Further more, this communicates to the consumer of that interface that it could dispose that service, which might not be correct, especially since in general, a resource should be disposed by the one who creates it (who has the ownership). When you inject a resource into a class (using constructor injection for instance), it is not clear if the consumer is given the ownership.

So in general the one responsible of creating that resource should dispose it.

However, in your case, you can simply prevent this from even happening by implementing a non-disposable implementation of ICustomerCreditServiceClient that simply creates and disposes the WCF client within the same method call. This makes everything much easier:

public class WcfCustomerCreditServiceClient
    : ICustomerCreditServiceClient
{
    public CreditLimit GetCreditLimit(Customer customer)
    {
        using (var service = new CustomerCreditServiceClient())
        {
            return service.GetCreditLimit(customer.Firstname,
                customer.Surname, customer.DateOfBirth);       
        }
    }
}

Answer 2

Starting again with the first implementation, I would try to add a getInterface-Request to the Class, so that the implementation could stay more or less the same. Then it can safely call Dispose (effectively it only defers the creation of the interface implementation, but stays in control of its life cycle): (c#-code not verified...)

public class MyClass()
{
  public delegate ICustomerCreditService InterfaceGetter;
  private InterfceGetter getInterface;
  public MyClass(InterfaceGetter iget)
  {
    getInterface = iget;
  }
  public DoSomething()
  {
    using (var customerCreditService = getInterface())
    {
       var creditLimit = customerCreditService.GetCreditLimit(customer.Firstname, customer.Surname, customer.DateOfBirth);       
    }
  }
}

Answer 3

Yes, it is. But that’s a necessary evil. The very existence of the IDisposable interface is a leaky abstraction. Leaky abstractions are simply an everyday fact of programming. Avoid them where possible but don’t fret when you can’t – they are ubiquitous anyway.

Answer 4

You should call the Dispose of the ICustomerCreditService where it has been instantiated as MyClass now has no idea of the lifecycle of ICustomerCreditService.

Answer 5

You should handle the lifecycle of the customerCreditService in the calling code. How should MyClass know if the service is still needed by the caller? If caller is responsible for cleaning up its resources then MyClass doesn't need to be disposable.

// calling method

using (var service = new CustomerCreditServiceClient()) {
    var myClass = new MyClass(service);
    myClass.DoSomething();
}

Update: In the comments OP mentioned the use of an IoC like Ninject. The code then could look like this:

IKernel kernel = ...;

using (var block = kernel.BeginBlock())
{
    var service = block.Get<ICustomerCreditService>();
    var myClass = new MyClass(service);
    myClass.DoSomething();
}

The kernel.BeginBlock() creates an activation block. It makes sure that the resolved instances are disposed when the block ends.