Reputation: 3839

Is it okay to write dispose method for a class?

I have a class (called Employee. non static) defined in a class library. I am instantiating that class in another project and calling some methods.

Is it okay to write a Dispose method in that class? The reason I wanted to write custom dispose method because I am calling a webservice inside Employee class.

public class Employee
{

    SoapSample company = new SoapSample();

    public Employee()
    {
        company.UserCredentials.UserName = "";
        company.UserCredentials.Password = "";
    }

}

Upvotes: 2

Answers (8)

supercat

Reputation: 81123

A class Foo should generally implement IDisposable in two cases:

At least some instances of `Foo` will know of some task that should happen sometime, but which no other object is likely to do in timely fashion, and they will know that the task in question may be safely performed once they themselves are no longer needed.
At least some classes derived from `Foo` are apt to meet the above criteria, and have their last useful references held by code which expects to work with them as type `Foo`, rather than a more derived type.

Something like Bitmap fits the first category, since when it is created it asks Windows to give it a GDI handle for its exclusive use, meaning: (1) Something needs to tell Windows when that handle is no longer needed; (2) If the Bitmap doesn't do it, nothing else will; (3) Once the Bitmap is no longer needed, the GDI handle may be safely deleted.

Something like Stream fits the second category. The base class isn't aware of any particular things that will need to be done before an instance can be safely abandoned, but many derived classes will have such requirements. Further, there are many cases in which an object may create a Stream for purposes of handing it off to some other object, and then have no further use for itself. The object creating the Stream shouldn't have to care about when the second object gets done with the stream, and the object receiving the Stream shouldn't have to worry about whether it's a type that actually requires cleanup or not. Instead, the simplest pattern is for the creator of the Stream to hand it over in a method that makes clear the recipient is expected to clean it up, and for the recipient to call Dispose without worrying about whether the method actually does anything in the particular type it was given.

Upvotes: 2

Jon Skeet

Reputation: 1500065

The web service client should be stateless anyway, I'd expect. What unmanaged resources would you want to dispose? Sounds like you don't need it.

EDIT: It feels like an odd design for an Employee type to have a reference to a soap client to start with, to be honest. Are you sure this is an appropriate design?

Upvotes: 5

Stilgar

Reputation: 23551

Do you need to keep the client object for the lifetime of the object? If not just dispose of the client inside the method you are calling it and if yes implement a disposable pattern.

Upvotes: 0

RQDQ

Reputation: 15569

You could just implement the IDisposable interface

public class Employee : IDisposable
{

    SoapSample company = new SoapSample();

    public Employee()
    {
        company.UserCredentials.UserName = "";
        company.UserCredentials.Password = "";
    }

    public void Dispose()
    {
         //TODO:put your cleanup code here
    }

}

Upvotes: 2

gdoron

Reputation: 150253

Yes... make that class implement IDisposable

public class Employee : IDisposable
{
        public void Dispose()
        {..}
}

But it will have a meaning only if that class uses an unmanaged resources.

When to use Dispose ? :

Use this method to close or release unmanaged resources such as files, streams, and handles held by an instance of the class that implements this interface. By convention, this method is used for all tasks associated with freeing resources held by an object, or preparing an object for reuse.

Upvotes: 1