Можно ли поместить логику в сеттер для свойства C #?

Question

Я смотрю на какой-то старый код, и мне интересно, уместно ли иметь логику в свойстве setter, или есть намного лучший способ написать это и почему?Спасибо!

        string qBankCode;
        string qCode;
        public string QBankCode
        {
            get => qBankCode;
            set
            {
                if (value.Length == 0)
                    throw new ArgumentException("You need to enter the question bank code as it is mandatory.");
                if (value.Length > 30)
                    throw new ArgumentException("Question bank code cannot exceed 30 characters.");
                qBankCode = value;
            }
        }
        public string QCode
        {
            get => qCode;
            set
            {
                if (value.Length == 0)
                    throw new ArgumentException("You need to enter the question code as it is mandatory.");
                if (value.Length > 30)
                    throw new ArgumentException("Question code cannot exceed 30 characters.");
                qCode = value;
            }
        }

Answer 1

В соответствии с Framework Design Guidelines :

Допустимо, чтобы установщик выбрасывал исключения

✓ НЕ сохраняйте предыдущее значение, если выбрасывает свойство установщикисключение.

✓ НЕОБХОДИМО, чтобы свойства устанавливались в любом порядке, даже если это приводит к временному недопустимому состоянию объекта.

, если они не зависят отсостояние других свойств, например

public string QCode
       { ... set {...
                if (QBankCode.Length ==10 && value.Length % 2 == 0)
                    throw new exception();...

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

✓ НЕОБХОДИМО предоставить разумные значения по умолчанию для всех свойств, ...

Answer 2

Это нормально?

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

---

Есть ли лучший способ?

или если есть намного лучший способ написать это и почему?

Это действительно зависит от того, как используется код.

Например, для моделей MVC или EntityFramework можно аргументировать атрибуты StringLength и Required.См. Добавление проверки к модели (C #) или StringLengthAttribute Class .

Если это действительно важно, его следует проверить на нескольких уровнях (throw и использовать атрибуты).

Атрибуты

Обратите внимание, что атрибуты требуют каркаса (MVC, EF и т. Д.) Для их применения, в то время как throw new ArgumentException будет работать при любых обстоятельствах, которые могут быть желаемым параметром.

Контракт

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

Интернационализация и строки конечного пользователя в целом

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

---

Сколько проверки в порядке?

Microsoft Свойство Design .NET Guide состояний

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

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

Я категорически не согласен с таким дизайном, но, как всегда, существуют сценарии, когда онсмысл.

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