使用自动属性实现单例是一个好主意吗？

Question

我最近发现了汽车属性并且非常喜欢它们。目前我正尝试在任何可以的地方使用它们。不仅仅是为了能够在任何地方使用它们，更多的是为了看看它们在大多数情况下的工作效果如何。

现在我正在创建一个单例并想：“嘿，让我们在这里也尝试一下自动属性”。

public class MySingleton
{
    public static MySingleton MySingleton { get; private set; }

    private MySingleton() {}

    static MySingleton() { MySingleton = new MySingleton(); }
}

所以我的问题是：“像这样实现单例是个好主意吗？”

我并不是在问单身人士总体上是否是一个好主意。

Answer 1

我个人不会这样做。我不喜欢使用带有私有 setter 的自动实现的属性，当您真正想要由只读变量支持的只读属性时，您永远不会调用该属性。只需再一行代码就可以更明确地表达您的意思：

public sealed class MySingleton
{
    private static readonly MySingleton mySingleton;
    public static MySingleton MySingleton { get { return mySingleton; } }

    private MySingleton() {}

    static MySingleton() { mySingleton = new MySingleton(); }
}

这样就没有人会试图更改单例类来重新分配属性或变量，因为编译器会阻止它们。他们必须添加一个设置器和/或使变量变为非只读，这是一个更大的更改 - 希望他们会重新考虑这一更改。

换句话说：

• 是的，它会起作用。
• 不，我认为这不是一个好主意。

从 C# 6 开始，使用自动实现的只读属性会更容易：

public sealed class MySingleton
{
    public static MySingleton MySingleton { get; } = new MySingleton();    
    private MySingleton() {}         
    static MySingleton() {}
}

Answer 2

我会从与乔恩稍微不同的方向来处理这个问题。 无论对象是否是单例，从逻辑上讲，它首先是否最好被建模为属性？

属性应该代表...属性。 （明显队长再次出击！）你知道。颜色。长度。高度。姓名。家长。所有你从逻辑上认为是事物属性的东西。

我无法想象一个对象的属性在逻辑上是单例。也许你已经想出了一个我没有想到的场景；今天早上我还没有吃胡椒博士的减肥药。但我怀疑这是对模型语义的滥用。

你能描述一下什么是单身人士，以及为什么你相信它是某物的属性吗？

话虽如此，我自己也经常使用这种模式；通常是这样的：

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();

就觉得奇怪。

在这种情况下，是拥有一个只读字段和一个常规属性更好，还是一个静态构造函数和一个 autoprop 更好，似乎不是一个有趣的问题，而是首先是否将其设为一个属性。出于“纯粹”的心情，我可能会站在乔恩一边，并将其设为只读字段。但出于懒惰，我也经常使用带有私有 setter 的 autoprop 模式来创建逻辑上不可变的对象。

全面考虑问题怎么样？

Answer 3

我看不出有什么理由说这是不正确的。毕竟，自动属性只是私有（编译器生成的）支持字段的访问器的语法糖。

Answer 4

当然，我不认为这有什么问题。

Answer 5

汽车财产？不，我不会，但会在单例上使用 setter，是的，我会这样做。我认为你想要对它拥有比汽车财产更多的控制权。

...这里非常欢迎建设性的反馈。在这家受人尊敬的公司中，这感觉像是一个勇敢（或愚蠢）的举动......

我的场景是，一个 WPF 应用程序有一个可以加载和保存的当前项目。当前的项目设置在整个应用程序中使用...

• 在 UI 中的 WPF 绑定中，以便用户可以更改设置，因此有了 INotifyPropertyChanged 界面。
• 我还使用 Fody.PropertyChanged 但这不会进行静态属性更改，因此 NotifyStaticPropertyChanged< /代码>。
• INotifyPropertyChanged 与单例属性上的 WPF 绑定配合得很好。
• Settings 的实例使用 JSON.NET 进行[反]序列化，因此单例上有 [JsonIgnore] 属性。我在将其加载到单例或将其保存到磁盘之前对其进行验证。
• 记录器是 Serilog。你记录东西，对吧？
• 单例是带有 public getter 的 public ，因为 WPF 绑定仅适用于公共属性。 internal setter 不会影响它。 Settings 的所有属性对于 WPF 绑定都是公共的。

我在代码中保留了所有“噪音”，因为有些人可能会发现它很有用。

class Settings : INotifyPropertyChanged
{
    private static Settings _currentSettings = new Settings();

    /// <summary> The one and only Current Settings that is the current Project. </summary>
    [JsonIgnore] // so it isn't serialized by JSON.NET
    public static Settings CurrentSettings //  http://csharpindepth.com/Articles/General/Singleton.aspx 
    {
        get { return _currentSettings; }

        // setter is to load new settings into the current settings (using JSON.NET). Hey, it works. Probably not thread-safe.
        internal set 
        {
            Log.Verbose("CurrentSettings was reset. Project Name: {projectName}", value.ProjectName);
            _currentSettings = value;
            _currentSettings.IsChanged = false;
            NotifyStaticPropertyChanged("CurrentSettings");
        }
    }

    // http://10rem.net/blog/2011/11/29/wpf-45-binding-and-change-notification-for-static-properties
    /// <summary> Fires when the Curent CurrentTvCadSettings is loaded with new settings
    ///           Event queue for all listeners interested in StaticPropertyChanged events. </summary>
    public static event EventHandler<PropertyChangedEventArgs> StaticPropertyChanged = delegate { };
    private static void NotifyStaticPropertyChanged(string propertyName)
    {
        StaticPropertyChanged?.Invoke(null, new PropertyChangedEventArgs(propertyName));
    }

    // various instance properties including ....

    public string ProjectName {get; set;}

    [JsonIgnore]
    public bool IsChanged { get; set; } 
}

用于将单例设置为新加载的项目，settings 只是

Settings settings = new Settings();
// load, save, deserialize, set properties, go nuts
Settings.CurrentSettings = settings;

setter 可能不是线程安全的，但我只将其设置在 UI 线程的一个位置，所以我并不害怕。您可以按照 http://csharpindepth.com/Articles/General 的受人尊敬的建议使其线程安全/Singleton.aspx

我意识到 OP 没有询问 WPF，但我认为它与展示为什么您可能想要设置单例相关。我这样做是因为这是最简单的解决方案。

Answer 6

使用 lambda 样式（>= C# 6）总结+替代语法，又名计算属性（又名表达式主体成员）：

该代码在功能上完全等同于 Jon Skeet 的答案，这里再次使用“实例”。我并不指望这会得到赞扬，但我认为这个更新的总结在一个地方进行了解释是值得的，因为这个 C#6 问题和答案扩展了旧的封闭线程，其中已经讨论了 Singleton 的变体。

您可能会认为带有显式缺失集的自动属性样式更清楚地表达了只读属性的意图，但最终它是基于样式的，并且这两种样式在现代 C# 中都很常见。

public sealed class MySingleton
{
    public static MySingleton Instance => new MySingleton(); // Assure that instantiation is only done once (because of static property) and in threadsafe way, and as this is an alternative style for a readonly-property, there is no setter
    private MySingleton() {} // Assure, that instantiation cannot be done from outside the class        
    static MySingleton() {} // Assure partly lazyness, see below     
}

以下是所有细节和历史参考：

关于懒惰的讨论：http://csharpindepth.com /Articles/General/Beforefieldinit.aspx
简单总结：只要类中没有引入其他静态字段/属性，上述实现就会表现出惰性。
（但这是一个可能依赖于 .NET 实现的领域。）

有关单例和线程安全的不同实现的讨论（较旧的 C# 样式）：
帖子

原始 关闭）：
C# 的单例模式