Отдельный класс Options, перегруженный конструктор или открытые свойства со значениями по умолчанию?

Question

Я работал над проектом, в котором у меня есть класс Worker, который генерирует много данных в многопоточном режиме. Тип, размер и расположение данных являются переменными в зависимости от большого набора параметров, которые могут быть установлены конечным пользователем. По сути, это большой набор тестов, который я использую, чтобы исследовать, как определенные вещи работают на основе изменений данных. Сейчас у меня есть как минимум 12 различных параметров для класса Worker. Я думал о переключении на отдельный класс WorkerOptions, который содержит все эти значения, а затем попросил пользовательский интерфейс создать объект WorkerOptions и затем передать его в Worker. Тем не менее, я мог бы также выставить открытые свойства в классе Worker, чтобы позволить соответствующим образом устанавливать параметры при создании Worker.

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

EDIT Обычно я не являюсь разработчиком на C #, я знаю достаточно, чтобы писать приложения, которые функционируют и следуют общим шаблонам проектирования, но я разбираюсь в SQL Server, поэтому я мог бы задать дополнительные вопросы, чтобы уточнить ваше значение.

Answer 1

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

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

Если число аргументов невелико, я использую аргументы со значениями по умолчанию, но вполне достаточно 12.

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

Answer 2

Я бы объединил два подхода.

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

Наличие класса WorkerOptions дает вам хороший DTO для передачи в случае, если рефакторинг приведет вас к созданию дополнительного слоя между пользовательским интерфейсом и самим рабочим классом.Использование обязательных параметров в его конструкторе дает вам проверку во время компиляции для предотвращения ошибок во время выполнения.

Answer 3

Лично из того, что вы сказали, я предпочитаю подход WorkerOptions. По следующим причинам:

• Это чище, о 12 параметрах конструктора не может быть и речи, но, возможно, это немного излишне.
• Вы можете применить полиморфизм и все остальные OO-качества к своим WorkerOptions. Возможно, вы захотите определить IWorkerOptions на некотором этапе или использовать Builder для создания различных подклассов WorkerOption.

Я бы также сделал все экземпляры WorkerOption неизменяемыми или, по крайней мере, придумал бы механизм «блокировки» или «замораживания» для предотвращения изменений после того, как Worker начал выполнение.