Конструктор со всеми свойствами класса или конструктор по умолчанию с методами set?

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

Например, если у вас есть что-то как это:

class Contact
{
    public Contact(string firstName, string lastName, string phoneNumber,
        string street, string city, string state, int zipCode) { ... }
}

я бы изменил его следующим образом:

class Contact
{
    public Contact(Person person, PhoneNumber number, Address address) { ... }
}

class Person
{
    public Person(string firstName, string lastName) { ... }
}

class PhoneNumber
{
    public PhoneNumber(string digits) { ... }
}

class Address
{
    public Address(string street, string city, string state, int zipCode) { ... }
}

Слишком большие классы - действительно распространенная проблема проектирования в базах кода ООП.

Вы пропустили самый большой про наличие конструктора с множеством параметров: он позволяет создавать неизменяемые типы.

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

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

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

и стандартный пустой конструктор

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

Недавние научные исследования (CMU и Microsoft) по юзабилити API позволяют предположить, что конструкторы по умолчанию с установщиками были бы подходом для удобства использования. Это из «Дейффа Стилоса и Стивена Кларка» «Последствия использования удобства требования параметров в конструкторах объектов» и было представлено на Международной конференции по разработке программного обеспечения:

Аннотация : Удобство использования API становится все более важным для производительности программиста. Основываясь на опыте изучения юзабилити конкретных API, были изучены методы изучения юзабилити вариантов проектирования, общих для многих API. Было проведено сравнительное исследование для оценки того, как профессиональные программисты используют API-интерфейсы с необходимыми параметрами в конструкторах объектов, в отличие от безпараметрических конструкторов «по умолчанию». Высказывалось предположение, что требуемые параметры позволят создать более удобные и самодокументируемые API, помогая программистам правильно использовать объекты и предотвращая ошибки. Однако в ходе исследования было установлено, что, вопреки ожиданиям, программисты предпочитали и были более эффективными с API, которые не требовали параметров конструктора. Участники

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

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

До этой темы я Я никогда не слышал об образце Строителя, о котором упоминает Роб. Никогда не использовал его сам (очевидно), но это чертовски интригующе.

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

Мне тоже нравится шаблон Builder, но самое важное правило: всегда используйте свой мозг и находите дизайн, который лучше всего соответствует конкретной проблеме. Единого универсального решения не существует.