What are the advantages of using a concept like IStartable?

Question

Instead of using an interface like this:

public interface IStartable
{
    void Start();
    void Stop();
}

I usually just make the constructor of an object run the Start() code, and implement IDisposable so that the dispose method runs the Stop() code.

Is it just a matter of style? Or am I missing something important by not having something like IStartable? All I see is extra complexity, because you have to maintain it's started/stopped state.

What are the pros and cons of using start/stop vs using ctor/dispose, especially in the context of an IoC/DI container?

EDIT: Great answers, you've convinced me to use an interface for startable objects. I can't decide who's answer is the best so I'll accept whoever has the most up votes after 24 hours.

Answer 1

The general advantage to using an interface is that they're self-describing and self-advertising. If there's no interface, you don't have a way to ask an object, "can you be started and stopped?" If you do use an interface, by contrast, you can query objects to see which of them will respond to those kinds of messages. Then you can be safely guaranteed that such objects have implemented the functionality encapsulated by the interface.