Управление объектами Конструкторы в нескольких версиях программного обеспечения - PullRequest
Новая
       302

Управление объектами Конструкторы в нескольких версиях программного обеспечения

4 голосов
/ 12 апреля 2011

Я проектирую библиотеку, в которой обсуждаю, должен ли я использовать конструктор для инициализации объектов в модели API.Мои соображения таковы:

  1. Используя конструктор, я могу указать, какие данные требуются для правильного объекта в соответствии с моделью.

  2. ОднакоИспользуя конструктор, мне любопытно, как сохранить код в том виде, в каком он был изменен, чтобы поддерживать это требование, не разбивая существующий код на основание кода.

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

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

dim objV1 as new ObjectOfSomeType(Param1, Param2, Param3)

VS 

dim objV1 as new ObjectOfSomeType()

objV1.Property1 = Param1
objV1.Property2 = Param2
objV1.Property3 = Param3

Ответы [ 4 ]

2 голосов
/ 12 апреля 2011

Минимальное требуемое начальное состояние для объекта, то есть данные, необходимые для того, чтобы объект вел себя детерминистически, должно быть установлено во время строительства.

Если вы сомневаетесь в способности клиентов, использующих ваш API, успешно конструировать ваши объекты, вам следует опубликовать класс, содержащий шаблон метода фабрики и поощрять и / или ограничивать его использование.

2 голосов
/ 12 апреля 2011

Если для проверки состояния объекта требуется инициализация некоторых свойств, то такие свойства должны быть инициализированы конструктором и сделаны доступными только для чтения .

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

Одним из возможных компромиссов является проектирование абстрактного базового класса с защищенными конструкторами , в то время как другие реализации могут наследовать и определять другие конструкторы и изменять поведение.

0 голосов
/ 12 апреля 2011

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

Я бы предложил просто следовать этим указаниям:

  1. Аргументами, которые ДОЛЖНЫ быть в вашем конструкторе, являются любые данные, которые, как ожидается, будут неизменными в течение всего времени жизни вашего объекта. Вы НЕ должны предоставлять сеттеры для них.
  2. Кроме того, вы можете НЕОБЯЗАТЕЛЬНО предоставлять другие аргументы переменных, которые будут обычно устанавливаться, просто чтобы сделать код немного проще для потребителя API. Это то, что, как вы знаете, будет обычно использоваться сразу после вызова конструктора. Так, скажем, например, если у вас есть объект User и переменная nickName внутри него, вы, вероятно, захотите предоставить опцию для этого в конструкторе, просто чтобы потребитель не всегда вызывал new User (); а затем user.setNickName («имя»); каждый раз, когда они создают объект.

Также стоит отметить, что вы должны быть в состоянии сделать то, что я описал, определяя только ОДИН конструктор, используя необязательные аргументы, если вы используете c #. http://msdn.microsoft.com/en-us/library/dd264739.aspx

0 голосов
/ 12 апреля 2011

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

Однако, используя конструктор, мне любопытно узнать, как поддерживать код в том виде, в каком он был изменен, чтобы поддерживать это требование, не нарушая существующий код по всей базе кода.

Я не совсем уверен, что вы имеете в виду: риск того, что позже вы поймете, что вам нужны дополнительные (или меньшие) параметры для создания действительных объектов? ИМХО , что должно быть смягчено тщательным проектированием, прототипированием и тестированием до публикации вашей библиотеки . Публичные API очень трудно изменить. В случае широко используемого, даже сломанные и устаревшие функции должны поддерживаться бесконечно (свидетель Object.clone() на Java). Что бы вы (или клиенты) ни делали для создания объекта, если требуемый параметр оказывается отсутствующим, это ошибка. ИМО, лучше определять такие случаи во время компиляции, чем во время выполнения, и конструкторы предоставляют самый простой и легкий способ добиться этого.

Другие варианты, которые вы можете рассмотреть:

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