Действительно ли осуществление - единичный предмет, используя автособственность хорошая идея?
Я недавно узнал об автосвойствах и как они довольно много. В данный момент я пытаюсь использовать их везде, где я могу. Едва ли, чтобы просто быть в состоянии использовать их везде, но больше видеть, как хорошо они работают в большинстве ситуаций.
Теперь я делаю единичный предмет и мысль: «Эй, давайте попробуем автосвойства здесь также».
public class MySingleton
{
public static MySingleton MySingleton { get; private set; }
private MySingleton() {}
static MySingleton() { MySingleton = new MySingleton(); }
}
Таким образом, мой вопрос: «Действительно ли это - хорошая идея осуществить единичный предмет как это?»
Я не спрашиваю, является ли единичный предмет в целом хорошей идеей.
4 ответа
Я бы лично не сделал это. Я не люблю использовать автоматически реализованные свойства с частным сеттером, который вы никогда не звоните, где действительно , вы хотите, чтобы свойство только для чтения, поддерживаемого переменной только для чтения. Это только еще одна линия кода, чтобы быть более явным о том, что вы имеете в виду:
public sealed class MySingleton
{
private static readonly MySingleton mySingleton;
public static MySingleton MySingleton { get { return mySingleton; } }
private MySingleton() {}
static MySingleton() { mySingleton = new MySingleton(); }
}
Таким образом, нет ни одного соблазн , чтобы изменить класс Singleton, чтобы переназначить либо свойство или переменную, потому что компилятор будет Останови их. Они должны были добавить сеттер и / или сделать переменную неречебно, что является большим изменением - тот, который, надеюсь, они пересматривают.
Другими словами:
- Да, это будет работать.
- Нет, я не думаю, что это хорошая идея.
По состоянию на C # 6, это проще с помощью только для чтения автоматически реализована свойства, хотя:
public sealed class MySingleton
{
public static MySingleton MySingleton { get; } = new MySingleton();
private MySingleton() {}
static MySingleton() {}
}
Я не вижу причин, почему это не будет правильным. В конце концов, автоматические свойства представляют собой просто синтаксический сахар для доступа к личному (сгенерированному компилятору).
Я бы подошел к этому немного иначе, чем Джон. Независимо от того, является ли объект одиночным, логически лучше всего моделируется ли он в первую очередь как свойство?
Свойства должны представлять... свойства. (Капитан Очевидный удары снова!) Вы знаете. Цвет. Длина. Высота. Имя. Родитель. Все вещи, которые вы логически считаете собственностью вещи.
Я не могу представить себе собственность объекта, который по логике является однокнопочным . Может быть, вы придумали сценарий, о котором я не думал; сегодня утром я еще не пробовал диету "Доктор Пеппер". Но я подозреваю, что это злоупотребление модельной семантикой.
Можете ли вы описать, что такое синглтон, и почему вы считаете, что он является свойством чего-то?
Все это говорит о том, что я сам часто использую этот образец; обычно вот так:
class ImmutableStack<T>
{
private static readonly ImmutableStack<T> emptystack = whatever;
public static ImmutableStack<T> Empty { get { return emptystack; } }
...
Является ли "пустота" логическим свойством незыблемого стека? Нет. Здесь убедительная польза от того, что я могу сказать
var stack = ImmutableStack<int>.Empty;
, превосходит мое желание, чтобы свойства логически были свойствами. Говорить
var stack = ImmutableStack<int>.GetEmpty();
кажется странным.
Лучше ли в этом случае иметь только для чтения поле и обычное свойство, или статический ктор и авторопропроп, кажется менее интересным вопросом, чем вообще делать его свойством. В "пуристическом" настроении я бы, скорее всего, встал на сторону Джона и сделал бы его только для чтения. Но я также часто использую схему создания автообъектов с приватными сеттерами для логически неизменяемых объектов, просто из лени.
Как это может быть, если принять все стороны вопроса?