Действительно ли необходимо ли получить доступ к переменной в том же классе через Свойство?
Поскольку ничто по сути не делает exports.save синхронным, вероятно, проще всего сделать validate асинхронным (и давайте также сделаем его современным, используя обещания и async).
exports.save = async function(req, res) {
const errors = await validate(req.body);
if (!errors.length) {
//add user
res.status(200).send(true);
} else {
res.status(500).send("oh bad");
}
};
async function validate(body) {
const errors = [];
const user = await User.findOne({ email: body.email });
if (user) {
errors.push({ msg: "Email already registered!" });
}
return errors;
}
6 ответов
Один из сильных аргументов в пользу доступа к локальным (область видимости) переменным через свойства заключается в том, что вы добавляете уровень абстракции в ваш класс. Если вы измените любую логику относительно того, как хранится это поле, тогда остальная часть вашего кода останется неизменной.
Например, вы можете изменить это с локальной переменной на свойство дочернего объекта, на вызов базы данных, на вызов веб-службы, на статическое свойство класса и так далее. При внесении изменения вы получаете единственную точку изменения - свойство, и вам не нужно обновлять остальную часть вашего класса, поскольку все они используют это свойство.
Кроме того, использование свойства позволяет применять бизнес-правила к значению свойства, вместо того чтобы применять одно и то же правило в каждом месте, где вы непосредственно обращаетесь к полю. Опять же, инкапсуляция
С введением автоматических свойств стало еще меньше причин явно указывать локальную переменную, если только вам не нужно применять бизнес-правила к get / set
Это зависит от того, хотите ли Вы применить какую-либо логику, реализованную в методе set свойства, и таким образом, действительно необходимо выбрать индивидуальное основание.
, Когда Вы переходите непосредственно к частному полю, Вы знаете, что поле устанавливается на точно, что Вы говорите.
при прохождении через Свойства значение установлено согласно логике метода set, таким образом, Вы получаете любые бизнес-правила или проверку, Вы хотите по значениям, присвоенным тому полю.
Довольно трудно для предложения правила о при выполнении любой 'корректен' о единственном, я сказал бы, что следую, то, что в инициализации конструктора я в значительной степени никогда не использовал бы Свойство.
Я думаю, что это - просто предпочтение.
, Хотя, я использую свойства намного больше в C# 3.0 с поддержкой автосвойства:
class Foo {
public string Value { get; set; }
public void Write() {
Console.Write(Value);
}
}
Обычно в зависимости от проекта, кодирующего стандарты, я использую "_" или "m", предшествующий названию моих частных атрибутов класса. (Как ниже)
private int mVariable;
private int _Variable;
С теми перед переменной я распознаю сразу же, что имею дело с внутренней переменной для класса. Тогда когда дело доходит до отладки позже я или кто-то еще можем сразу распознать, что код имеет дело с внутренней частной переменной, и внесите корректировку. Таким образом, это сводится к удобочитаемости для меня.
Да, я думаю, что вы должны использовать свойства внутри ваших классов, когда это возможно. Свойства являются более гибкими и позволяют добавлять логику для проверки его значения в центральном месте.
Вы также можете отложить инициализацию поля всякий раз, когда свойство используется вместо принудительного выполнения его в конструкторе (или везде, где используется поле). Пример:
class Test {
private int _checksum = -1;
private int Checksum {
get {
if (_checksum == -1)
_checksum = calculateChecksum();
return checksum;
}
}
}
Всегда Свойства Использования, Вот некоторые причины
- Просты в использовании. В Visual Studio можно использовать "Вкладку Вкладки Опоры". Вы получите отрывок свойства
- , Свойства являются элементами языка, к которым получают доступ, как будто они - элементы данных
- .Net классы платформы используют его, классы кода привязки данных в свойствах Поддержки платформы.NET,
- , Свойства имеют все функции языка методов. Свойства могут быть виртуальные