Проверить на равенство перед назначением?

Question

Является ли хорошей практикой присваивать значение, только если оно не равно цессионарию? Например, будет:

bool isVisible = false;      
if(TextBox1.Visible != isVisible)
    TextBox1.Visible = isVisible;

быть более желательным, чем:

bool isVisible = false;      
TextBox1.Visible = isVisible;

Кроме того, зависит ли ответ от типа данных, например от объекта с более дорогим методом Equals, от объекта с более дорогим методом присвоения?

Answer 1

С точки зрения читабельности, я бы определенно предпочел второй способ - просто назначить чертову вещь.

Answer 2

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

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

Answer 3

Ваши инстинкты кажутся правильными - это зависит от стоимости операций.

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

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

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