C# 不雅/不当使用属性？

我有一个类，我用它作为对象的描述符。在该描述符中，有几个类的

Type

引用，这些类将针对涉及该对象的不同操作进行实例化。我正在考虑取出这些引用，并用描述符类上的属性替换它们

由此：

class MyDescriptor : BaseDescriptor {
    public Type Op1Type { get; }
    public Type Op2Type { get; }
}

为此：

[Op1(typeof(foo))]
[Op2(typeof(bar))]
class MyDescriptor : BaseDescriptor {
}

---

我很少使用属性。这会被认为是对它们的错误使用吗？

我个人会使用依赖项注入，而不是在编译时将依赖项烘焙到类型本身中

我看不出这样做会给您带来什么好处，而不是通过类在其构造函数或初始化中实例化依赖项

---

依赖项注入允许您在运行时更改此类行为，此外还可以使用虚拟存根/模拟来替换它们

我看不到您使用属性的方式有任何问题，但我也看不到您获得的任何好处。如果您共享更多信息，可能会更容易找到解决方案。

我认为这是对属性的一种很好的使用，特别是如果您希望能够在实例化装饰类之前通过反射来实例化装饰类。使用属性有很多好处，这只是其中之一

---

不管您的意图如何，我看不出实现有任何问题。

当我想指定要使用的哈希算法提供程序的类型时，我使用这种方式

---

子类具有将由父类读取的属性，它将创建该类型的实例。

属性在源代码中是一种相当优雅的表达方式，但运行时性能不佳

---

您需要在运行时构建缓存以加快查找速度，可能需要使用

字典

您是否考虑过改用泛型？一个问题是，如果使用属性，您需要在编译时了解公共接口的类型。使用虚拟方法允许使用编译时未知的类型。派生类可能有不同数量的操作，因此我无法拥有静态数量的泛型参数。CodeInChaos，您有一个有效的参数。虽然在当前的设计中没有任何东西需要对描述符进行子类化，但也没有任何东西阻止它。DI仍然更适合这样做。的确，从编码的角度来看，没有任何明显的好处。我希望获得的好处是从惯例的角度来看的。我对DI很陌生，只是在我最近的工作中接触过它。在这种情况下，我对它不太满意，所以无法尝试实现它，但我会把你的建议作为这方面研究的出发点。这正是你想要的。使用Unity、Castle、StructureMap或任何其他易于实现的工具。