Question

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

例如，我正在处理的项目包含两种不同的用户类型。他们是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>();

这有多大意义吗？我正试图在这些情况下找出最佳实践。

Answer 1

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

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

Answer 2

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

我相信模式很好。我也相信滥用它们是纯粹的邪恶：）

如果你开始看到你的编程范式让你的生活更加艰难，那么放弃这种范式，而不是程序员的能力。有时太多的抽象根本没用。

清洁并编写干净的代码并不意味着遵循模式，意味着编写有意义的代码。

工厂模式：如果我们必须为工厂编写工厂，为工厂编制工厂工厂....直到截止日期到来，当我们编写实际代码时？

由于我认为系统分析师更像建筑师而不是砌砖工，我相信只要遵循一些规则就无法使你的软件变好。

如果他们愿意，人们可以责怪图灵，教会或Goedel，但如果编写软件的软件无法编写，则不是他们的错误:) 我们仍然需要我们的人力部分来编写软件，我们的创造力和想象力以及我们的灵魂，如果某些软件工程师试图使其成为一种纯粹的机械行为，编程仍然是其中很大一部分的艺术。

结论：我认为如果使用正确的批评并遵循优秀的程序员的第六感，模式是非常好的：）

我认为编程需要一些灵活性，我们不是一个完美的世界，我们没有完美的电脑，我们并不完美，我们的软件也不能完美，特别是机器无法思考，仍然。

因此，调用构造函数总是比2000行代码更好地调用构造函数。

Answer 3

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

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

Answer 4

您通常只会在创建多种类型时使用工厂模式，并且您希望隐藏创建以防止出现诸如此类的丑陋内容：

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

然后你可以这样做：

Person.CreatePerson(newPerson);

同样，这只有在你不得不做多个地方的陈述时才有意义。

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

是否值得抽象出单个类的对象创建？

5 个答案: