我可以使用属性,以便我的工厂知道它可以/应该实例化什么,而不破坏“松散耦合”结构吗?规则?
我在我的项目中实现了一个工厂,最近有人建议我在类上使用属性,以便工厂可以确定要实例化并传回哪个类。我是开发世界的新手,试图严格遵循松散耦合的规则,我想知道依赖“钩子”(作为属性)是否违背了这一点?
I have implemented a factory in my project and it was recently suggested that I use attributes on my classes so the factory can determine which class to instantiate and pass back. I am new to the world of development and trying to rigidly follow the loosely-coupled rule, I wondering if relying on "hooks" (being the attributes) goes against this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
装饰工厂的产品类可以使开发变得更加容易,这是我有时会做的事情。例如,当必须基于数据库中存储的唯一标识符创建产品时,这尤其有用。该唯一 ID 和产品类别之间必须存在映射,并且使用属性可以使映射变得非常清晰和可靠。除此之外,它还允许您添加产品类别,而无需更改工厂。
例如,您可以像这样装饰您的类:
您可以像这样实现您的工厂:
完成此操作后,您可以使用该工厂来创建如下产品:
我过去使用过这个概念,例如创建基于发票计算的发票在数据库标识符上。该数据库包含每种发票类型的计算列表。实际计算是在 C# 类中定义的。
Decorate product classes of a factory can make development much easier and it is something I sometime do. This is especially useful when products must be created based on a unique identifier stored in a database for instance. There must be a mapping between that unique id and the product class and using an attribute makes this very clear and reabable. Besides this, it allows you to add product classes, without changing the factory.
For instance, you can decorate your class like this:
And you can implement your factory like this:
After doing this you can use that factory for creating products like this:
I've used this concept in the past for instance to create invoice calculations based on a database identifier. The database contained a list of calculations per type of invoice. The actual calculations were defined in C# classes.
我不认为使用属性会增加工厂与其创建的类之间的耦合,事实上,它会减少这里的耦合,因为工厂将在运行时通过属性发现信息。如果有的话,您只需用正在创建的类之间的耦合来交换与属性的耦合。也就是说,我不确定这会给你带来什么。工厂的要点是将创建逻辑本地化在一个地方。通过将其放入属性中,您再次将其分布在代码中,部分地违背了工厂的目的:现在您必须查看工厂和属性来了解对象是如何存在的创建的。
当然,我可能误解了你的问题。您可能意味着类使用其属性上的属性来指示哪些属性需要由工厂实例化。在这种情况下,您将替换一些配置驱动的机制来执行依赖项注入。我当然知道这可能有用;让工厂发现对象的依赖关系并在运行时自动创建它们。在这种情况下,您将稍微增加代码的整体耦合度,因为现在属性和工厂之间存在以前不存在的依赖关系。总的来说,尽管您可能会降低代码复杂性,因为您无需为每个类提供特定代码即可提供其特定依赖项或从配置文件中发现它们。
如果您询问使用属性是否是一个好主意,我认为我们可能需要更多信息,但由于您似乎只是询问是否会违反 OO 原则,所以我不这么认为。我没有看到它增加了工厂和正在创建的类之间的耦合,而只是稍微增加了代码的整体耦合。无论如何,工厂本质上比其他类需要更多的耦合。请记住,它是松耦合,而不是非耦合。 解耦代码不执行任何操作。你需要类之间的关系才能使任何事情发生。
I don't think that using attributes would be increasing the coupling between the factory and the class it creates, in fact, it would decrease the coupling here because the factory would be discovering the information at runtime via the attributes. If anything you're simply trading the coupling between the class being created for the coupling to the attribute. That said, I'm not sure exactly what that buys you. The point of the factory is that you localize the creational logic in a single place. By putting it into attributes you've spread it all over your code again, partially defeating the purpose of the factory: now you have to look at both the factory and the attribute to understand how the object is being created.
Of course, I may be misunderstanding your question. You may mean that a class uses attributes on it's properties to indicate which of the properties need to be instantiated by the factory. In this case, you're replacing some configuration-driven mechanism for doing dependency injection. I can certainly see where that might be useful; having the factory discover an object's dependencies and automatically create them as well at runtime. In this case, you'd be slightly increasing the overall coupling of your code, since there is now a dependency between the attribute and the factory that didn't exist before. Overall, though you might decrease code complexity since you'd be able to do without specific code for each class to supply its particular dependencies or discover them from a configuration file.
If you're asking if using attributes a good idea, I think we probably need more information, but since you seem to be asking only if you're going to violate an OO principle, I don't think so. I don't see it increasing the coupling between the factory and the class being created and only slightly increasing the overall coupling of the code. Factories, by their nature, need more coupling than other classes anyway. Remember, it's loosely-coupled, not uncoupled. Uncoupled code doesn't do anything. You need relationships between classes to make anything happen.
这是一个工厂实现,我用它来根据属性值创建具体实例。它还使用参数进行实例化。
Here is a factory implementation that i used to create concrete instances based on a attribute value. It also instantiates with parameters.
如果有人需要使用 System.Reflection.Emit 的版本...
In case anyone needs a version that uses System.Reflection.Emit...