Почему предпочитают Свойства общедоступным переменным? [дубликат]
Вы можете использовать full join:
select indiv_id, a.january, b.march
from a full join
b
using (indiv_id);
Предложение using делает это особенно удобным, потому что вам не нужно беспокоиться о каких-либо coalesce() в select.
8 ответов
У нас уже была эта тема, но сейчас я ничего не могу найти.
Вкратце: ваши потребности могут измениться: там, где сейчас нет проверки на работоспособность, она может потребоваться в будущем. Однако, если вы измените свои общедоступные поля на свойства, это нарушит бинарную совместимость: каждому клиенту, использующему ваш код / библиотеку, придется перекомпилировать.
Это плохо , потому что потенциально это стоит больших денег.
Использование свойств с самого начала позволяет избежать этой проблемы. Это даже относится к коду, который не является частью библиотеки. Почему? Потому что вы никогда не знаете: код (даже если он сильно зависит от предметной области!) Может оказаться полезным, поэтому вы захотите преобразовать его в библиотеку. Этот процесс рефакторинга, очевидно, становится намного проще, если вы уже используете свойства вместо общедоступных / защищенных полей.
Кроме того, писать общедоступные свойства в C # 3.0 легко, потому что вы можете просто использовать автоматически реализованные свойства, что сэкономит вам довольно много кода:
public DataType MyProperty { get; set; }
Будет реализовано необходимое поле поддержки и код геттера / установщика.
От себя добавлю: .NET ведет себя в этом отношении несколько лениво. Компилятор мог просто менять общедоступные поля на свойства на лету, избегая таким образом проблемы. VB6 уже сделал это для классов, открытых для COM, и я не вижу абсолютно никаких причин для VB.NET и C # не делать то же самое. Возможно, кто-нибудь из команды компиляторов (Джаред?) Сможет это прокомментировать.
В двух словах:
- Вы можете контролировать доступ (только чтение,
только для записи, для чтения / записи) - Вы можете проверить значения при настройке свойство (проверьте на нулевое значение и т. д.)
- Вы можете выполнить дополнительную обработку, такие как ленивая инициализация
- Вы можете изменить базовый реализация. Например, собственность может быть поддержана членом переменная, но вы можете изменить ее поддерживаться строкой БД без нарушение любого пользовательского кода.
Jeff Atwood has blogged about it:
There are valid reasons to make a trivial property, exactly as depicted above:
- Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.
- You can't databind against a variable.
- Changing a variable to a property is a breaking change.
It's a shame there's so much meaningless friction between variables and properties; most of the time they do the exact same thing. Kevin Dente proposed a bit of new syntax that would give us the best of both worlds:
public property int Name;Однако, если различие между переменной и свойством является такой постоянной проблемой, мне интересно, есть ли более радикальное решение в порядке. Разве мы не можем полностью отбросить переменные в пользу свойств? Разве свойства не делают то же самое, что и переменные, но с более детальным контролем видимости?
Вы также можете защитить доступ на запись и разрешить доступ на чтение со свойством:
public int Version { get; private set; }
Изменение поля на свойство в будущем считается критическим изменением . Поля считаются деталями реализации классов, и их публичное раскрытие нарушает инкапсуляцию.
Если вы работаете в закрытой среде - вы не разрабатываете SDK, все классы используются в рамках одного проекта - нет никакой разницы.
Обычный аргумент заключается в том, что " в будущем вам может потребоваться проверить значения, чтобы было проще со свойствами ». Я не покупаю это вообще.
Использование открытых полей более читабельно, меньше украшений и проще в использовании.
Использование свойств делает ваш код более объектно-ориентированным. Обнародовав переменные-члены, вы раскрываете свою реализацию.
Также см. Эту ссылку из Руководства по программированию в C #
Да.
Рассмотрим общедоступную переменную, которая теперь содержит строку, вы можете просто установить ее. Однако, если вы решите, что эта общедоступная переменная должна содержать объект, который должен быть инициализирован строкой, вам придется изменить весь код, используя исходный объект. Но если бы вы использовали setter, вам нужно было бы только изменить setter, чтобы инициализировать объект предоставленной строкой.