О конструкторах - PullRequest
5 голосов
/ 18 января 2010

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

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

Редактировать : Извините за способ, которым я задал вопрос. Да, мы создаем объект с конструктором и присваиваем значения с помощью установщиков, но мой вопрос касается сравнения конструктора по умолчанию с сеттерами и конструктора с явными параметрами .

Ответы [ 7 ]

11 голосов
/ 18 января 2010

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

Как правило, не рекомендуется иметь огромных чиселпараметры, будь то конструктор или нормальный метод.Если вы обнаружите, что у вас много параметров, вы можете захотите создать тип, представляющий все связанные с ним значения - , который может иметь набор методов получения / установки.См. ProcessStartInfo для примера этого.

10 голосов
/ 18 января 2010

Я вижу это так:

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

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

4 голосов
/ 18 января 2010

Вы должны вызвать сеттеры для объекта, а конструктор создает этого объекта. Без вызова конструктора у вас не будет объекта для вызова.

Re. количество параметров. Если у вас есть значительное количество параметров, это означает:

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

Проверьте шаблон Factory и шаблон Builder для некоторых альтернатив. создание объектов.

Еще одна нота. Параметры конструктора и сеттеры. В Java и C # параметры, передаваемые в конструктор, могут использоваться для инициализации полей только один раз, и поля являются неизменяемыми с этой точки (в отличие от того, когда вы устанавливаете их через установщики). Это имеет большие преимущества для надежности кода (при некоторой стоимости неизменности объекта).

3 голосов
/ 18 января 2010

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

Обратите внимание, что вы также можете перегружать конструктор.

2 голосов
/ 18 января 2010

Если у вас есть несколько необязательных и много необязательных параметров, и вы хотите избежать длинных списков параметров в конструкторах (которые могут быть очень подвержены ошибкам, особенно если параметры одного типа), вы должны отдать предпочтение использование

Шаблон строителя

вместо.

0 голосов
/ 18 января 2010

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

  • Состояние: Под состоянием я подразумеваю значение всех полей объекта в снимке времени выполнения. При разработке приложения важно отслеживать состояние объекта, особенно если объект будет доступен в нескольких потоках. Даже в однопоточном программировании объекты могут быть изменены в различных методах и классах, особенно в таких языках, как Java, в которых все объекты передаются по ссылке. Установка состояния раз и навсегда за время существования объекта (в конструкторе) и отказ от установщиков (так называемый неизменяемый шаблон) делает программирование, особенно параллельное программирование, действительно проще. Но обратите внимание, что этот подход увеличивает стоимость модификации объекта, потому что все поля должны быть скопированы в новый экземпляр при каждой модификации; например, в Java, сравните String (который является неизменным) с StringBuilder и StringBuffer (которые с состоянием). String является поточно-ориентированным и простым в использовании, но дорогостоящим для создания длинных строк, в то время как StringBuilder не является поточно-ориентированным, но быстро объединяет небольшие строки. Между тем, StringBuffer является и состоящим, и потокобезопасным, но дорогостоящим при каждом вызове метода, потому что его методы синхронизированы (Это означает: не делайте объект с сохранением состояния потокобезопасным, когда это не требуется в большинстве случаи применения). Итак, в качестве общего совета: используйте конструкторы (и неизменный шаблон) для объектов, к которым обращаются в нескольких потоках, и используйте сеттеры для локальных объектов и полей, которые находятся под большим контролем.

  • Внедрение: Когда мы используем среду внедрения зависимостей, такую ​​как Spring или Guice , среда делает один метод более предпочтительным, чем другой , Например, пружина поощряет инъекцию сеттера больше, чем инъекцию конструктора. Spring конструирует объекты (бины) в основном с использованием конструкторов по умолчанию, а затем вводит зависимости с помощью методов установки. Затем Spring вызывает для вас метод init (PostConstruct). Таким образом, вы можете выполнить любую инициализацию в этом методе с зависимостями на месте. В отличие от этого, Guice поощряет внедрение конструктора как лучшую практику.

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

  • В new или To Delegate: Всякий раз, когда вы собираетесь new объект, будь то с помощью методов конструктора или метода установки для заполнения полей, он Это хорошая практика, чтобы подумать, может ли когда-нибудь понадобиться, чтобы кто-то еще передал (внедрил, создал) это здесь Это приводит к шаблону проектирования Factory , который особенно полезен при разработке инструментов и библиотек.

0 голосов
/ 18 января 2010

Также можно рассмотреть использование шаблона Factory для создания объекта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...