如何在领域驱动设计中使用带有工厂模式的接口?
默认情况下为域对象工厂使用接口是否有意义,或者仅在需要时才为工厂类保留接口?
public IUserFactory
{
User CreateNewUser();
}
public UserFactory : IUserFactory
{
public User CreateNewUser()
{
return new User();
}
}
Does it make sense to use interfaces for your domain object factories by default, or should interfaces be reserved for the factory classes only when you need them?
public IUserFactory
{
User CreateNewUser();
}
public UserFactory : IUserFactory
{
public User CreateNewUser()
{
return new User();
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
并非所有东西都必须有接口; 如果你只有一个实现,并且没有理由有任何其他实现,我不明白为什么要定义一个接口。
Not everything has to have an interface; if you have a single implementation of something, and no reason to have any other I can't see why define an interface.
这是将同一问题翻译成 Java 的结果。
原始示例
然后是工厂的实现
我没有看到为工厂定义接口有任何特殊的好处,因为您正在为集中式生产者定义单个接口。 通常,我发现我需要生产同一类型产品的许多不同实现,并且我的工厂需要消耗许多不同类型的参数。 也就是说,我们可能会:
工厂看起来像这样:
希望这能传达要点。
Here's a translation of the same problem into Java.
Original example
Then the implementation of the Factory
I don't see any special benefit to defining an interface for the factory, since you're defining a single interface for a centralized producer. Typically I find that I need to produce many different implementations of the same kind of product, and my factory needs to consume many different kinds of parameters. That is, we might have:
The factory would look like this:
Hope this gets the point across.
有两件事:(1)我会等到我需要(或看到迫在眉睫的需要)替代实现后再创建接口,(2)接口几乎总是使单元测试变得更容易,特别是在模拟方面,所以我经常来立即满足对接口的需求。
Two things: (1) I'd wait until I needed (or saw a looming need) an alternative implementation before I'd create the interface and (2) interfaces almost always make unit testing easier, especially with mocking, so I frequently come up with a need for an interface right away.
通过接口创建工厂可以更轻松地使用模拟类测试它们,也使使用 IoC 应用程序变得更简单,因此虽然我可能不一定需要它们来实现应用程序功能,但我通常通过接口构建和调用大多数类。
如果您不考虑单元测试或 IoC 模式(抛开宗教观点),我可能不会打扰。
我发现使用它们的最大痛苦(至少在 Visual Studio 中)是属性或函数上的“转到定义”会跳转到接口定义,而不是类定义。
Creating the factory off an interface allows it much easier to test them with mock classes, as well as making it simpler to use IoC applications, so whilst I may not necessarily need them for the application functionality, I generally build and call most classes through interfaces.
If you are not considering Unit Tests or IoC patterns (religious opinions aside), I probably wouldn't bother.
I find the biggest pain with using them, in Visual Studio at least, is that 'Go To Definition' on a property or function jumps to the Interface definition, not the class definition.
在你给出的例子中,我什至不明白为什么你需要去工厂。
你是否有不同类型的用户,或者用户本身就是某种类型。可能你没有清楚地阐述这一点。我们通常在中使用接口 >抽象工厂方法模式,我们需要处理多个相关对象系列
注意:不要忘记,模式是为了帮助我们,这并不意味着我们必须使用它们,因为它们是可用的。 ,无论我们是否需要它们。
In your given example, I don't even see why you need to go Factory.
Do you have a different type of Users, or User is itself a type of something. May be you didn't elaborate the thing clearly. We usually use interface in abstract factory method pattern, where we need to deal with multiple families of related objects.
NOTE: Don't forget, patterns are there to help us, it doesn't mean that we must use them because they are available, whether we need them or not.