Redudancia interface with Disposable

Asked

Viewed 144 times

1

I saw an example of implementing a interface with Disposable which I think is redundant and I would like to know whether I am right.

Following example to illustrate:

public interface IClassBase<TEntity> where TEntity : class
{
        void Add(TEntity obj);
        void Dispose();
}

To inteface above brings as contract the method Dispose


public class ClassBase<TEntity> : IDisposable, IClassBase<TEntity> where TEntity : class
{

    public void Add(TEntity obj)
    {
        throw new NotImplementedException();
    }

    public void Dispose()
    {
        throw new NotImplementedException();
    }
}

So, IDisposable already obliges me to implement the method Dispose() it being unnecessary to add this method to my interface IClassBase, this reasoning is correct?

2 answers

3

In your example, the recommended would be that your interface implementasse Idisposable:

public interface IClassBase<TEntity> : IDisposable where TEntity : class
{
    void Add(TEntity obj);
}

This way you force classes to implement your interface, also implement Idisposable.

On the other hand, maybe that doesn’t make much sense, because Idisposable is usually implemented by classes that use native methods and need to release manually used resources, which will not be released by Garbage Collecor.

So what you need to know is: It makes sense for you to create an interface that forces you to implement Dispose?

I usually don’t care about that, I let whoever is implementing my interface decide whether or not they need Idisposable, and in that case, I implement Idisposable directly in the class. Remembering that it is recommended to implement Dispose in set with the finalizer class. Because Garbage Collector does not call Dispose, only the class finisher.

Remembering also another resource quite useful when a class implements Idisposable, is the possibility to use the object within a block using. Ensuring correct use of Idisposable by calling Dispose automatically at the end even if an error occurs.

UPDATE: since the answer is not clear, so here goes:

No. It is not redundant. The method name is just a name. As I explained above, the Idisposable interface has these particularities, like the possibility of using the block. And as I said, the implementation of the interface is another "hint" that the class uses native code that needs to release something manually.

You can have your own Dispose method and you can also implement Idisposable.Dispose. Simply implement the interface explicitly:

using System;

namespace ConsoleApplication1
{
    internal interface IMyDisposable
    {
        void Dispose();
    }

    internal class MyDisposable : IMyDisposable, IDisposable
    {
        public void Dispose()
        {
            Console.WriteLine("Dispose da interface IMyDisposable");
        }

        void IDisposable.Dispose()
        {
            Console.WriteLine("método implementando explicitamente Dispose da interface IDisposable");
        }
    }

    internal class Program
    {
        private static void Main(string[] args)
        {
            using (var m = new MyDisposable())
            {
                m.Dispose();
            }

            //ou então:
            var m2 = new MyDisposable();
            m2.Dispose();
            ((IDisposable)m2).Dispose();

            /*
            print:
            Dispose da interface IMyDisposable
            método implementando explicitamente Dispose da interface IDisposable
             */
        }
    }
}
  • 1

    Although her answer is correct, she makes no sense for what was asked.

  • Explain why not, and I can update.

  • Where are you saying about use redundancy?

  • I didn’t understand the question exactly about "redundancy", but about whether or not to implement the Idisposable interface. And in my answer I try to explain a little bit about use. The fact that the method is called Dispose does not make the implementation of the Idisposable interface exactly redundant, since the method created with this name could have any other.

  • The question is very clear that it is about redundancy. That’s exactly what I said, you explained something else, not what was asked. It’s in the title saying it’s about redundancy, it talks about it in the first paragraph, and the last paragraph where the question is asked describes a redundancy.

  • okay.............

Show 1 more comment

3


And who guarantees that you will use the interface IDisposable in the class that will also use the IClassBase<TEntity>? Having the Dispose() it is guaranteed that you will have to implement the method. If you don’t have it, it becomes an option. I’m actually being nice to talk about option. It’s an option like? Does the documentation say to do that? If it is, it doesn’t guarantee anything, and I don’t even know if it’s the documentation’s job to do that. The fact is that without guarantees in statically typed language, it is a conceptual error not to have it.

Remember that the function of the interface is to be a contract, is to ask your implementers to require certain methods. So it must require all. You can’t expect a coincidence to do what you want. If you leave that method out of it, you’re saying it doesn’t matter. Moreover, if the access is done by the interface, you cannot call the Dispose() if it is not listed there. The type protects from access to other members. Already I answered that in another question.

Not that it is forbidden, it has reasons to do this, pragmatically speaking, but conceptually using an interface and saying that its method will not be implemented means that the interface should not be used. I know it can be implemented later, no problem, but it is good to make this warning to those who do not understand this.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.