我理解静态和实例的概念，但我很困惑当我有一个只有一个实例的类时我应该使用哪个实例，它是在我的应用程序开始时调用的实例（=Application.Current.MainWindow）
我想保留一个列表，我需要在我的程序中一直使用不同的课程。我是否应该将其设为静态，因为永远不会存在 2 个 MainWindow 实例？或者我应该让它成为非静态的，因为它听起来是正确的，它属于实例？
如果我选择使它成为非静态的，这也意味着我总是需要在其他类中使用“(MainWindow)Application.Current.MainWindow”来引用它，这很烦人
在这里将列表设为静态会“不好”吗？
静态似乎不是那么大的问题。不过，如果您觉得这很奇怪，您可以制作一个“单例”，MainWindow供程序的其余部分使用。
请参阅文档：http: //msdn.microsoft.com/en-us/library/ff650316.aspx
如果您使用实例模式，它为依赖注入和模块发现铺平了道路 ，这反过来又有助于对使用该服务的组件进行单元测试。
实例模式还提供了后期绑定，如果类需要一些直到运行时才知道的东西，这将非常有用。最后，实例模式启用了“可变性”。
如果您的应用程序是通过各种服务的交互构建的，那么静态模式可能更合适。
两者之间的性能和内存占用差异可以忽略不计。
很难说没有看到你的代码或了解你的工作文化。
恕我直言：只要您关于“只有一个实例”的假设成立，那么您就可以摆脱静态属性和方法。这让我觉得有点可疑。
如果您是与我一起工作的初级或中级，那么我希望您养成使用实例属性、方法和事件的习惯，并在需要时保留使用静态成员。
只是我的2c。对此的看法会有所不同。
上面Servy的评论得到了我的认可，顺便说一句。
我认为将其设为静态会很糟糕，但是如果您的程序小而简洁，那么您不太可能会看到副作用，从而得出相同的结论。
该列表包含可能需要与其他类共享的项目，可以包含在主窗口的单独类中，并且由此类实现的接口可以公开所需的功能，涉及列表访问或操作。
您可能想尝试阅读“依赖注入”。您可以让 IOC 容器控制列表封装类的生命周期，并且只将接口暴露给其他应用程序类。