Is it a leaky abstraction if implementation of interface calls Dispose

空扰寡人 提交于 2019-11-29 13:39:11

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);       
        }
    }
}

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

FrankB

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);       
    }
  }
}

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!