Сегодня на работе один из моих коллег просмотрел мой код и предложил удалить свойство «только для набора» и использовать вместо него метод.
Поскольку мы оба были заняты другими делами, он сказал мне взглянуть на Property Design
раздел из книги «Руководство по разработке структуры». В книге писатель просто сказал, чтобы избежать:
Свойства с установщиком, имеющим более широкий доступ, чем получатель
И теперь мне интересно, почему не рекомендуется иметь свойство set-only? Может кто-нибудь уточнить для меня?
design
code-quality
code-reviews
code-smell
Прашант Чолачагудда
источник
источник
Password
свойствоUser
класса. Вы можете установить это, но вы не можете получить это. Тогда вы могли бы иметьHashedPassword
свойство только для чтения . Вызов набора сделал бы хэш и изменил быHashedPassword
свойство. Я бы не стал кричать на тебя, если бы ты сделал это.Ответы:
Я думаю, что это может иметь отношение к ожиданиям. Свойства только для наборов встречаются редко, и свойства обычно используются для «тупых» наборов просто для хранения значения без особой обработки. Если вы выполняете большую работу в сеттере, лучше использовать метод - люди ожидают, что выполнение методов может занять много времени и иметь побочные эффекты. Реализация подобного типа поведения в свойстве может привести к коду, который нарушает ожидания.
Вот соответствующий раздел Руководства Microsoft по использованию собственности :
источник
Потому что это просто не имеет смысла в большинстве случаев. Какое свойство вы можете иметь, которое вы можете установить, но не прочитать?
Если ОО предназначен для лучшего представления реального мира, свойство «только набор» может указывать на то, что ваше моделирование не в порядке.
Изменить : См. Также: /programming/4564928/are-set-only-properties-bad-practice, который по существу говорит, что это не интуитивно понятно, а свойство только для набора является в основном методом с другим именем, поэтому вы должны использовать метод.
источник
Foo Foo { private get; set; }
? Я бы не назвал это только записьюНу, я представляю, что если вы можете установить свойство для чего-либо, но никогда не получите его, вы никогда не узнаете, если что-то еще изменит / переопределит значение, которое вы установили. Это может быть проблемой, если вы полагаетесь на установленное вами значение и не можете (по какой-то причине) сохранить его до того времени, когда вы захотите его получить.
Использование метода вместо свойства только для набора будет немного менее запутанным для пользователя. Имя метода , как правило , указывает на комплект- или get- , но имена свойств обычно не указывают , что что - то может только быть установлен и не быть получены. Я предполагаю, что если бы свойство было чем-то вроде «ReadOnlyBackgroundColour», это не могло бы сбить с толку других кодеров, но это выглядело бы странно.
источник
Это очень старая тема, но она зашла в мою точку зрения на этом позднем этапе, и я хотел бы получить некоторые комментарии, поскольку я пытаюсь обосновать свойства только для записи ...
У меня есть набор
ActiveReport
классов, которые являются частью веб-сайта, которые создаются и запускаются при обратной передаче после нескольких пользовательских выборов.Код VB выглядит примерно так:
В этих отчетах используются общие функции,
CommonReader
используются хранимая процедура и массив значений по умолчаниюSqlParameter
, каждый из которых имеет соответствующее свойство WriteOnly, которое, в зависимости от дизайна отчета, может быть передано в качестве параметра при создании экземпляра или задано пользователем после создания экземпляра до вызовRun
метода отчетов .Итак, как я понимаю, имея свойство только для записи в этом случае
SqlParameter
s являются общимиSqlParameter
s являются классами, а не примитивными значениями, свойства WriteOnly позволяют упростить интерфейс для настройки параметров.Так что это мои мысли.
Могу ли я вместо этого преобразовать его в метод? конечно, но интерфейс кажется ... менее приятным
против
источник