是否值得为单个类抽象出对象创建？答案

【问题标题】：Is it worth abstracting out Object creation for single classes?是否值得为单个类抽象出对象创建？
【发布时间】：2011-08-31 20:45:30
【问题描述】：

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

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

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

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.");
    }
}

然后：

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

这是矫枉过正吗？我正在尝试在这些情况下制定最佳实践。

【问题讨论】：

到目前为止，答案似乎相当一致！我想我正在考虑对接口进行编程，因此从代码中删除具体类的 all 引用。我不知道应该走多远。
当然由你决定，但我仍然说你在为自己创造不必要的工作。等到对接口进行编码是实际问题的最简单解决方案，而不是“良好的编程风格”。

标签： c# design-patterns factory

【解决方案1】：

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

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

【讨论】：

这篇文章并没有真正解决何时/如何使用工厂模式。这更像是一种普遍的陈词滥调。如果意图是说“永远不要使用工厂模式”，那么这篇文章太可怕了。如果我的答案中的示例与此方法一起使用，那么您最终可能会得到 15 个分支 if 语句。通过测试并不是好的编程风格的代名词。
恕我直言，“良好的编程风格”并不意味着使用 GOF 设计模式只是说您阅读了这本书。应该使用设计模式来解决常见的问题。如果您不需要工厂模式，那么您就没有需要解决的问题。
我不确定这与我所说的有什么不同...我指出了一个不重构的情况，即仅做使测试通过所需的事情，将在您的代码中导致重大的维护问题。显然，您不应该使用不会增加代码可维护性的模式！
您的代码在需要维护之前不需要“可维护性”。您将如何测试工厂代码以确保它符合您的要求？如果您的要求不包括“始终使用工厂”，那么您将针对哪些要求进行测试？您的要求（标准是技术要求）是否规定您必须为所有课程使用工厂？如果是这样，那么您当然必须使用工厂，并且您需要一个。否则，您将浪费时间生成不必要的代码，因为它是“良好的编程风格”。
我曾在具有该原则的系统上工作过。 10 年过去了，维护是一场噩梦。代码在所有地方都重复了很多，以至于如果进行了适当的重构，一个小的功能更改可能需要在 15 个或更多地方进行代码更改，而不是一个。几乎不可能判断是否所有需要的更改都已完成，因为从未重构任何内容。

【解决方案2】：

好的……你需要一个工厂类，或者只是，你需要调用构造函数。为什么人们害怕调用构造函数？

我相信模式是好的。我也相信虐待他们是纯粹的邪恶:)

如果您开始发现您的编程范式让您的生活变得更加艰难，那么请放弃该范式，而不是您的程序员能力。有时过多的抽象根本没有用。

干净和编写干净的代码并不意味着遵循某种模式，而是意味着编写有意义的代码。

工厂模式：如果我们必须为工厂编写工厂，为工厂编写工厂......直到最后期限到来，当我们编写真正的代码时？

由于我将系统分析师视为架构师而不是砌砖工，因此我相信仅遵循某些规则无法使您的软件变得更好。

如果他们愿意，人们可以责怪 Turing、Church 或 Goedel，但如果无法编写编写软件的软件，这不是他们的错 :) 我们仍然需要我们人类的部分来编写软件，我们的创造力和想象力以及我们的灵魂，如果一些软件工程师试图将其变成一种纯粹的机械行为，那么编程在很大程度上仍然是一门艺术。

结论：我相信模式是非常好的，如果与正确的批评一起使用并始终遵循优秀程序员的第六感:)

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

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

【讨论】：

【解决方案3】：

在这种特殊情况下，与简单地调用构造函数相比，您的解决方案没有任何好处。如果您有工厂的理由，那么一定要这样做。否则，不要过度复杂您的代码。

如果你的控制器总是知道它将创建什么样的用户（即它总是会在你的类型参数中传递一个具体的类型），你就不需要工厂。

【讨论】：

【解决方案4】：

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

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

你可以这样做：

Person.CreatePerson(newPerson);

同样，这仅在您必须在多个地方使用 if then 语句时才重要。

【讨论】：

【解决方案5】：

我会说你的信息：

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 ）完全不相关的类（从设计角度来看）您应用的工厂模式可能非常适合恕我直言。

祝你好运。

【讨论】：