C# 为单个类抽象出对象创建是否值得？

我在玩弄设计模式，事情进展得很顺利。我不确定的一点是，当当前只有一个对象时，是否值得抽象出对象创建

例如，我正在处理的一个项目包含两种不同的用户类型，它们之间没有任何关联。他们是学生，也是老师。对于所讨论的应用程序，将永远不会有任何其他类型的用户（员工角色处理与系统的所有非学生交互）

在我的控制器中，我可以简单地：

IStudent student = new Student();

或者我是这样的：

public static class UserFactory
{
    public static T Create<T>() where T : class
    {
        if(typeof(T) == typeof(IStudent))
            return new Student() as T;

        if (typeof(T) == typeof(IStaff))
            return new Staff() as T;

         throw new Exception("The requested user type is not valid.");
    }
}

公共静态类UserFactory
{
公共静态T Create（），其中T:class
{
if（typeof（T）=typeof（IStudent））
将新学生（）返回为T；
如果（类型（T）=类型（IStaff））
将新员工（）返回为T；
抛出新异常（“请求的用户类型无效”）；
}
}

然后：

IStudent student = UserFactory.Create<IStudent>();

IStudent student=UserFactory.Create（）；

---

这是不是太过分了？我正在努力找出这些情况下的最佳实践。

就我个人而言，我使用TDD进行大多数开发。我喜欢的一点是，它为您的问题提供了答案：“除非需要通过失败的单元测试，否则不会”

---

换句话说，如果您不需要它，那么就不要这样做。

在这种特殊情况下，您的解决方案与调用构造函数相比没有任何好处。如果你有一个工厂的理由，那么无论如何。否则，不要使代码过于复杂

---

如果您的控制器总是知道要创建什么类型的用户（即，它总是要在您的类型参数中传入具体类型），则不需要工厂。

通常，在创建多个类型时，您只会使用工厂模式，并且希望隐藏创建，以防止出现以下丑陋的情况：

if(newPerson == "student")
 person = new Student();
else if(newPerson == "Staff")
 person = new Staff();

然后你可以做：

Person.CreatePerson(newPerson);

---

同样，只有当您必须在多个位置执行if-then语句时，这才重要。

好的。。。您需要一个工厂类，或者只需要调用构造函数。 为什么人们害怕呼叫构造器

我相信模式是好的。我还认为，虐待他们纯粹是邪恶的：）

如果你开始发现你的编程模式让你的生活变得更艰难，那么放弃这种模式，而不是你的编程能力。 有时候，太多的抽象是毫无用处的

保持干净并编写干净的代码并不意味着遵循模式，而是意味着编写有意义的代码

工厂模式：如果我们必须为工厂写工厂，为工厂写工厂。。。。直到最后期限到来，我们什么时候写真正的代码

因为我认为系统分析员更多的是架构师而不是砖匠，所以我相信仅仅遵循一些规则并不能使您的软件变得好

如果人们愿意，可以指责图灵、丘奇或戈德尔，但如果编写软件的软件无法编写，这不是他们的错：） 我们仍然需要我们人类的一部分来编写软件，我们的创造力、想象力和我们的灵魂，而且如果一些软件工程师试图把它变成一种纯粹的机械行为，编程在很大程度上仍然是一门艺术

结论：我相信模式是非常好的，如果使用时有正确的批评，并且始终遵循优秀程序员的第六感：）

我认为编程需要一定的灵活性，我们不是在一个完美的世界里，我们没有完美的计算机，我们不是完美的，我们的软件不可能完美，尤其是机器不能思考

---

因此，调用构造函数总比只调用构造函数的2000行代码要好。

我想说您的消息：

there will never be any other types of user (staff Roles handle all none-student interactions with the system)

与此非常相似：

640K of memory is all that anybody with a computer would ever need

换句话说，正如Sounders建议的那样，尽可能使用更简单的代码，但请记住，总有一天会发生一些变化，即使今天看起来不可能

编辑

如果您有一系列类型（而不仅仅是2个）完全不相关的类（从设计角度来看），那么您应用的工厂模式可能非常适合IMHO

---

祝你好运。

这篇文章并没有真正说明何时/如何使用工厂模式。这更像是一种陈词滥调。如果目的是说“永远不要使用工厂模式”，那么这篇文章很可怕。如果我的答案中的示例与此方法一起使用，那么最终可能会出现15条分支If语句。通过测试并不是良好编程风格的同义词。IMHO，“良好编程风格”并不意味着使用GOF设计模式只是为了说你读了这本书。应该使用设计模式来解决常见问题。如果你不需要工厂模式，那么你就没有需要解决的问题。我不知道这和我说的有什么不同。。。我指出了这样一种情况，即不进行重构（即只执行使测试通过所需的操作）将导致代码中出现重大的维护问题。显然，您不应该使用不增加代码可维护性的模式！您的代码在需要维护之前不需要“可维护性”。您将如何测试出厂代码以确保其满足您的要求？如果您的需求不包括“始终使用工厂”，那么您将测试哪些需求？您的要求（以及标准是技术要求）是否规定您必须为所有类别使用工厂？如果是这样，那么当然你必须使用一个工厂，你需要一个。否则，您将浪费时间生成不必要的代码，因为这是“良好的编程风格”。10年过去了，维修简直是一场噩梦。代码到处重复，如果进行了适当的重构，一个小的功能更改可能需要在15个或更多的地方进行代码更改，而不是在一个地方进行代码更改。几乎不可能知道是否所有需要的更改都已完成，因为没有任何更改