C# 将属性用作工厂方法

我有一个基类

base

，它需要创建另一种类型

trerequired

的实例，但是，只有来自

base

的派生类才知道如何构造这些实例

使用抽象属性作为工厂方法是一种糟糕的风格吗？e、 g

protected abstract TRequired NewTRequired { get; }

我应该出于某种原因使用某种方法吗？有没有关于我为什么应该/不应该在此处使用属性的指南？

您肯定应该使用一个方法，因为访问此成员会做一些事情。调用方法是让代码在这方面为自己说话的好方法

或者，如果您更喜欢另一个透视图：对成员的两个后续访问将返回不同的结果。一个好的经验法则是在任何情况下都使用一种方法，以避免违反规则

这看起来像是在读取一个变量的结果，即使您知道

NewTRequired

是一个属性（与字段相反），您也知道实际上它在运行任意代码：

var prototype = Factory.NewTRequired;

我特意将结果放入一个名为

prototype

的变量中，以便更好地表明，即使是了解这段代码的读者也很容易被抛弃：看到这一点并认为“正确，因此

newrequired

是X的原型对象”是合理的。读者一定会对这样的代码结果感到惊讶：

var eq = object.ReferenceEquals(prototype, Factory.NewTRequired);

将其与工厂方法进行对比。现在，此代码可能会发出轻微的气味：

// hmmm... are we actually using this as a prototype?
// because it sure looks like an instance created just for the occasion.
var prototype = Factory.NewTRequired();

这段代码永远不会让你吃惊：

// obviously should be false, the code screams "I am creating new instances!"
var eq = object.ReferenceEquals(Factory.NewTRequired(), Factory.NewTRequired());

---

这是一个著名的例子，说明此规则实际上是属性。

我建议使用一种方法：

protected abstract TRequired CreateRequired();

创造意味着“工作”的发生。与属性相比，这更适合于方法，因为属性getter意味着通常会在不执行太多代码的情况下快速返回的内容

---

甚至您的问题标题“property as factory method”（属性作为工厂方法）也暗示工厂方法应该是一种方法。

属性是为“类似”字段的内容设计的，例如对象的位置

每次获得新实例时都返回新实例的属性是非常糟糕的设计

你应该改用一种方法