使用像 IStartable 这样的概念有什么优点?

发布于 2024-07-21 10:56:39 字数 436 浏览 11 评论 0原文

而不是使用这样的接口:

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

我通常只是让对象的构造函数运行 Start() 代码,并实现 IDisposable 以便 dispose 方法运行 Stop() 代码。

这只是风格问题吗? 或者我是否因为没有像 IStartable 这样的东西而错过了一些重要的东西? 我所看到的只是额外的复杂性,因为您必须维护它的启动/停止状态。

使用 start/stop 与使用 ctor/dispose 的优缺点是什么,特别是在 IoC/DI 容器的上下文中?

编辑:很好的答案,你说服我使用可启动对象的接口。 我无法决定谁的答案是最好的,所以我会接受 24 小时后得票最多的人。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

不回头走下去 2024-07-28 10:56:39

使用界面的一般优点是它们是自我描述和自我广告的。 如果没有接口,您就无法询问对象“可以启动和停止吗?” 相比之下,如果您确实使用接口,则可以查询对象以查看其中哪些对象将响应这些类型的消息。 然后你就可以安全地保证这些对象已经实现了接口封装的功能。

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.

儭儭莪哋寶赑 2024-07-28 10:56:39

一般来说,构造函数应该生成一个正确初始化的对象

,仅此而已!

in general, constructors should produce a properly-initialized object

and nothing more!

很糊涂小朋友 2024-07-28 10:56:39

具体来说,这可能取决于您说 Start() 时要发生的事情。 但一般来说,将对象初始化与例程执行(尤其是有状态和/或长时间运行的执行!)混合在一起会违反 SoC

它还留下了很大的歧义。 对于消费者来说,对于给定的对象,当我们调用构造函数时,我们如何知道它正在“启动”? “对于这个给定的对象,它不执行任何契约,我必须把它留给作者,希望它符合我的期望”? 界面使操作的存在和可用性变得明确。

It could possibly depend on what, specifically, you mean to be happening when you say Start(). But in general, mixing object initialization with routine execution (especially stateful and/or long-running execution!) violates SoC.

It also leaves a great deal of ambiguity. To a consumer, for a given object how do we know it is "starting" when we invoke the ctor? "For this given object, which implements no contract, I must leave it to hope in the author that it conforms to my expectations"? An interface makes the presence and availability of the action explicit.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文