Общедоступные поля по сравнению с автоматическими свойствами
String.prototype.toPrice = function () {
var v;
if (/^\d+(,\d+)$/.test(this))
v = this.replace(/,/, '.');
else if (/^\d+((,\d{3})*(\.\d+)?)?$/.test(this))
v = this.replace(/,/g, "");
else if (/^\d+((.\d{3})*(,\d+)?)?$/.test(this))
v = this.replace(/\./g, "").replace(/,/, ".");
var x = parseFloat(v).toFixed(2).toString().split("."),
x1 = x[0],
x2 = ((x.length == 2) ? "." + x[1] : ".00"),
exp = /^([0-9]+)(\d{3})/;
while (exp.test(x1))
x1 = x1.replace(exp, "$1" + "," + "$2");
return x1 + x2;
}
alert("123123".toPrice()); //123,123.00
alert("123123,316".toPrice()); //123,123.32
alert("12,312,313.33213".toPrice()); //12,312,313.33
alert("123.312.321,32132".toPrice()); //123,312,321.32
5 ответов
В вопросе , который у меня был некоторое время назад, была ссылка на публикацию в блоге Джеффа, объясняющую некоторые различия.
Свойства и общедоступные переменные
- Отражение работает по-разному с переменными и свойствами, поэтому, если вы полагаетесь на отражение, проще использовать все свойства.
- Невозможно привязать данные к переменной.
Изменение переменной свойства - критическое изменение. Например:
TryGetTitle (out book.Title); // требуется переменная
Игнорируя проблемы API, я считаю наиболее ценным в использовании свойства отладку.
Отладчик CLR не поддерживает точки прерывания данных (это делает большинство собственных отладчиков). Следовательно, невозможно установить точку останова при чтении или записи определенного поля в классе. Это очень ограничивает в определенных сценариях отладки.
Поскольку свойства реализованы как очень тонкие методы, можно установить точки останова на чтение и запись их значений. Это дает им большие преимущества над полями.
При переходе от поля к свойству контракт нарушается (например, требуется перекомпилировать весь ссылочный код). Итак, когда у вас есть точка взаимодействия с другими классами - любым публичным (и обычно защищенным) членом, вы хотите спланировать будущий рост. Делайте это, всегда используя свойства.
Ничего такого, чтобы сделать его автоматическим свойством сегодня, а через 3 месяца вы поймете, что вы хотите сделать его ленивой загрузкой, и поставьте нулевую проверку в геттер. Если вы использовали поле, это изменение в лучшем случае связано с перекомпиляцией, а в худшем - невозможно, в зависимости от того, кто и что еще полагается на ваши сборки.
Если вы решите позже проверить уникальность заголовка, сравнив его с коллекцией или базой данных, вы можете сделать это в свойстве, не меняя код, который от него зависит.
Если вы используете только публичный атрибут, вы будете иметь меньшую гибкость.
Дополнительная гибкость без нарушения контракта - вот что для меня наиболее важно при использовании свойств, и, пока мне действительно не понадобится гибкость, автоматическое создание имеет наибольший смысл.
Все дело в управлении версиями и стабильности API. В версии 1 нет разницы, но позже, если вы решите, что вам нужно сделать это свойство с каким-либо типом проверки ошибок в версии 2, вам не нужно менять свой API - никаких изменений кода нигде, кроме определение собственности.