Должны ли свойства объекта быть заполнены в конструкторе - PullRequest
2 голосов
/ 23 января 2009

Я разрабатываю новое приложение, и я не решил, нужно ли мне указывать свойства моего объекта в конструкторе

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, если это имеет значение.

Ответы [ 6 ]

3 голосов
/ 23 января 2009

Мое мнение:

Конструктор создает объект. Конструктор класса User должен создать нового пользователя.

Статический член работает как getUser получение объекта, который уже существует.

Я бы использовал последнюю форму.

1 голос
/ 23 января 2009

Я бы использовал Factory-Pattern, сделал бы конструктор частным / защищенным и сделал бы статический метод NewObject (). Затем метод NewObject может вызвать соответствующий конструктор. Преимущество в этом заключается в том, что если вам нужно изменить поведение объекта во время выполнения, вы можете подключить (переопределить) метод NewObject и использовать свой собственный метод NewObject, «смешанный». Недостатком этого является то, что он может быть очень сложным и очень быстрым, особенно если вы отлаживаете его.

1 голос
/ 23 января 2009

Это действительно зависит от языка, поскольку некоторые языки не могут гарантировать состояние объекта до тех пор, пока конструктор и все базовые конструкторы не завершат выполнение.

Я считаю, что лучше всего заполнить членов, которые вам нужны, а затем вызывать методы для выполнения остальной части работы. Это делает код более читабельным, так как в ваших конструкторах не будет много кода.

1 голос
/ 23 января 2009

Мне нравится, чтобы типы были неизменяемыми, если это не создает других проблем. Для типа «человек» это может не подойти, но стоит задуматься. Вам также следует попытаться сконструировать объекты так, чтобы после вызова конструктора объект находился в допустимом состоянии.

С другой стороны, вы должны стараться не делать слишком много работы в самом конструкторе - это то место, где статические фабричные методы имеют тенденцию быть хорошими, так как они могут выполнять значительную работу для сбора всех данных, необходимых для создания объекта затем передайте его простому конструктору, чтобы создать законченный, действительный и потенциально неизменный объект.

0 голосов
/ 23 января 2009

Объект должен быть на 100% готов к использованию при его создании. Конструктор по умолчанию должен иметь разумные ненулевые значения по умолчанию для всех ссылок.

Если вы обнаружите, что ваш конструктор имеет «слишком много» кода, возможно, пришло время подумать о рефакторинге этого объекта.

0 голосов
/ 23 января 2009
  1. Вы создаете экземпляр объекта userhandler и используете его для получения разных пользователей и позволяете работать со всеми пользователями. Имейте GetUser-функцию и ничего в конструкторе.

  2. Вы являетесь пользователем объекта и работаете только с пользователем, иметь конструктор, работающий с пользователем ведьмы.

Мои 5 центов.

...