我做了很多“设计自己的____”应用程序。
我做的是我做一个单例类来保存用户选择的所有自定义。例如：当你选择你想要的东西是绿色的，它会更新一个getton/setter在单例中是绿色的。然后，当应用程序需要知道选择了什么颜色时，它会从同一个getter/setter获取信息。
我用来做到这一点的方式是将信息存储在UI中（只需检查从下拉菜单中选择了什么颜色）。
在阅读了关于MVC（我还没有完全理解MVC）之后，我现在知道这是完全错误的，这就是为什么我将它抽象为包含所有这些的单例类。这是Singleton模式的一个很好的用法吗？
现在我想知道这是不是一个坏主意？如果是的话，我应该怎么做呢？
谢谢。
我会说这不是真正的Singleton模式的目的。这是一种非常被误解的模式，人们使用它的最常见的原因似乎是它很容易访问，因为它们通常是静态的。真正发生的情况是，你有一个配置问题，你试图通过一个静态单例来解决，该单例可以很容易地在整个应用程序中访问。当试图控制对真正有限的资源的访问时，“正确的”使用会是。
如果您认为对应用程序只有一个通用“配置”可能确实没有意义。它有更多的意义，有几个，但也许只有一个曾经在同一时间使用。
-Edit- 而不是使用可以静态访问的单例，可以考虑使用依赖注入或控制反转。
我是一个Service Layer家伙（虽然我有我自己的服务层愿景），会推荐做一些IoC并将所有定制逻辑移动到单独的服务（AmbienceService或其他）。因此，在你的演讲，你会做（C＃风格的伪代码）：
viewModel.HeaderColor = ServiceLocator.Resolve<AmbienceService>().HeaderColor;
我不能完全确定你的问题，但这里是什么什么，我做的吧。
您的应用程序逼抢后有一个用户界面，允许用户选择一堆参数（例如下拉一组颜色。其中之一是绿色。）
后来（例如应用程序并重新启动它）所选的值需要再次加载。
如果这是你的具体问题，我真的不认为这与单身模式本身有什么关系。我想你想要的是一个配置文件（应用程序的app.config和Web应用程序的web.config）。 使用ConfiguratoinManager类，您可以轻松访问这些类。
单身人士通过设计将实例数量限制为一个。在你的情况下，你为什么决定你必须只有一个实例？如果你想要多种配置呢？您的设计无法实现多个代表不同配置的实例。
我假设你正在谈论的东西像car configurator - 选择油漆，引擎，轮辋和所有其他的东西。
在这种情况下，我不会使用单身。不是因为它不起作用，而是因为它看起来语义上是错误的。单身意味着只有一种状态。但是你的应用程序可能有两个窗口 - 就像两个文件。对于单身人士，你不能独立修改两个文件，因为他们共享他们的状态。所以你看，它真的不应该是一个单身人士。
您的问题的答案可能与您当前的环境有很大关系。例如，在Java运行时属性通过System.getProperties等提供.Windows有其注册表。
你有没有想过使用上下文来传输状态的解决方案？你真的需要全球性？你的属性可以在运行时改变吗？你会有多个线程可能修改相同的属性吗？这些都是设计中需要考虑的一切。
就个人而言，我通常只是选择任何似乎是我工作环境的约定。从你最后一个问题来看，这听起来像你正在使用ActionScript，是否有一个已经存在的约定？
这不是你应该使用的模式。我认为你应该尝试一种状态模式。当您需要访问来自许多不同地方的有限资源时，Singleton适用。
就像打开和读取配置文件一样。而不是阅读同一个文件的不同类，他们通过一个只做这个的类。您需要的是，当用户更改设置时，需要通知系统已更改某些内容。
但这真的取决于您使用的语言。据我所知，只有java有一个onNotify（）方法。但我可能是错的。
请记住，一个单例基本上是一个全局变量，并具有所有相同的问题。例如：
我知道将一个对象传递给需要它的程序的每个部分是一种痛苦。但是这最终会导致更好的设计。
试图分开你的问题描述了一下，所以我可以尝试包围我的头。 – 2009-04-27 14:30:38
更多单身东西 - http://stackoverflow.com/questions/726685/yeah-i-know-im-a-simpleton-so-whats-a-singleton – madcolor 2009-04-27 15:17:35