Каковы преимущества использования такой концепции, как IStartable?

Question

Вместо использования интерфейса, подобного этому:

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

Обычно я просто заставляю конструктор объекта выполнять код Start () и реализовывать IDisposable, чтобы метод dispose выполнял код Stop ().

Это просто вопрос стиля? Или я что-то упускаю из-за отсутствия чего-то вроде IStartable? Все, что я вижу, - это дополнительная сложность, потому что вы должны поддерживать состояние запуска / остановки.

Каковы плюсы и минусы использования start / stop и ctor / dispose, особенно в контексте контейнера IoC / DI?

РЕДАКТИРОВАТЬ: отличные ответы, вы убедили меня использовать интерфейс для запускаемых объектов. Я не могу решить, кто ответит лучше всех, поэтому я приму того, кто наберет наибольшее количество голосов через 24 часа.

Answer 1

Основным преимуществом использования интерфейса является то, что он описывает себя и саморекламу. Если интерфейса нет, у вас нет способа задать объекту: «Можно ли запустить и остановить?» Напротив, если вы используете интерфейс, вы можете запрашивать объекты, чтобы узнать, какие из них будут отвечать на сообщения такого типа. Тогда вы можете быть уверены, что в таких объектах реализована функциональность, заключенная в интерфейсе.

Answer 2

в общем, конструкторы должны создавать правильно инициализированный объект

и больше ничего!

Answer 3

Это может зависеть от того, что именно вы имеете в виду, когда говорите Start (). Но в целом смешивание инициализации объекта с рутинным выполнением (особенно с сохранением состояния и / или длительным выполнением!) Нарушает SoC .

Это также оставляет много двусмысленности. Для потребителя, для данного объекта, как мы узнаем, что он «запускается», когда мы вызываем ctor? «Для данного объекта, который не реализует контракт, я должен оставить надежду у автора, что он соответствует моим ожиданиям»? Интерфейс делает явным наличие и доступность действия.