Design patterns 是否应该在构造函数中填充对象属性

我正在设计一个新的应用程序，我还没有决定是否应该在构造函数中填充我的对象属性

Public Sub New(UserId as integer)
    ' get database values
    dr = DataReader
    Me.FirstName = dr.fields(0)
    Me.LastName = dr.fields(1)
End Sub

或者为每种对象类型创建一个具有方法的工厂

Public Function getUser(UserId as integer) as User
    Dim myUser as new User
    ' get database values
    dr = DataReader
    myUser.FirstName = dr.fields(0)
    myUser.LastName = dr.fields(1)
    return myUser
End Function

我意识到代码很粗糙，但我希望它足以让我的观点被理解。我已经看到了这两种方法的实施，但不确定长期的优缺点是什么

---

具体地说，我使用的是VB.NET，如果有必要的话。

我喜欢类型是不可变的，这样就不会产生其他问题。对于“人”类型来说，这可能不合适，但值得考虑。您还应该尝试构造对象，以便在调用构造函数后，对象处于有效状态

---

另一方面，您应该尽量避免在构造函数本身中做太多的工作-这是静态工厂方法比较好的地方，因为它们可以做大量的工作来获取构造对象所需的所有数据，然后将其传递给简单的构造函数以创建完整的，有效且可能不可变的对象。

它实际上取决于语言，因为在构造函数和所有基本构造函数完成执行之前，某些语言无法保证对象的状态

我发现最好填充您需要的任何成员，然后调用方法来完成其余的工作。这会使代码更具可读性，因为构造函数中不会有太多代码。

我的观点：

构造函数创建一个对象。

用户

类的构造函数应该创建一个新用户

静态成员函数，如

getUser

检索已存在的对象

我会使用后一种形式

您正在实例化userhandler对象，并使用它来获取不同的用户，并允许您处理所有用户。 有一个GetUser函数，构造函数中没有任何内容

您正在实例化userobject并仅与用户一起工作， 让构造器和用户一起工作

---

我的5美分。

我将使用工厂模式，使构造函数私有/受保护，并生成一个静态NewObject（）方法。然后，NewObject方法可以调用相应的构造函数。 这方面的优点是，如果您需要在运行时更改对象的行为，您可以插入（覆盖）NewObject方法并“混合”您自己的NewObject方法。

---

这样做的缺点是，它可能会变得非常复杂，速度非常快，尤其是在调试它时。

一个对象在构建时应该100%准备好使用。对于所有引用，默认构造函数应该具有合理的非空默认值

---

如果你发现你的构造函数有太多的代码，也许是时候考虑重构这个对象了。p> 我同意。这样，也就不需要在用户类中引用DataReader。这样，您就可以在其他secnarios中使用您的用户对象，并通过设置它们来简单地填充其值。