我是否以正确的方式使用静态?

发布于 2024-10-30 02:39:21 字数 174 浏览 0 评论 0原文

我正在编写一个 XNA 引擎,并将所有模型存储在 List 中。为了能够在整个引擎中使用它,我将其设为公共静态列表,以便我可以从我开发的任何新类访问它。这当然也使得获取模型列表变得非常容易,但是这是正确的用法吗?或者我最好在方法声明中实际传递一个变量?

I'm writing an XNA engine and I am storing all of the models in a List. In order to be able to use this throughout the engine, I've made this a public static List<Model> so I can access it from any new classes that I develop. It certainly makes obtaining the list of models really easy to get too, but is this the right usage? Or would I be better off actually passing a variable through in a method declaration?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

摇划花蜜的午后 2024-11-06 02:39:21

在 OOP 中,通常建议避免使用静态方法和属性,除非有充分的理由这样做。原因之一是,将来您可能出于某种原因想要拥有此列表的两个或多个实例,然后您将陷入静态调用的困境。

静态方法和属性过于严格。正如 Stevey 所说:

静态方法与
花岗岩。每次使用时,
你正在将你的程序的一部分投射到
具体的。只要确保你不这样做
把你的脚卡在那里
你看着它变硬。有一天你
你会惊讶地发现,天哪,你
确实需要另一个实施
那个该死的 PrintSpooler 类,以及
它应该是一个接口,一个
工厂,以及一套实现
类。哦!

In OOP it's generally advisable to avoid using static methods and properties, unless you have a very good reason to do so. One of the reasons for that is that in the future you may want to have two or more instances of this list for some reason, and then you'll be stuck with static calls.

Static methods and properties are too rigid. As Stevey states it:

Static methods are as flexible as
granite. Every time you use one,
you're casting part of your program in
concrete. Just make sure you don't
have your foot jammed in there as
you're watching it harden. Someday you
will be amazed that, by gosh, you
really DO need another implementation
of that dang PrintSpooler class, and
it should have been an interface, a
factory, and a set of implementation
classes. D'oh!

要走干脆点 2024-11-06 02:39:21

对于游戏开发,我主张“做可能有效的最简单的事情”。这包括使用全局变量(C# 中的 public static),如果这是一个简单的解决方案的话。您以后随时可以将其变成更正式的内容。 Visual Studio 中的“查找所有引用”工具使这变得非常简单。

话虽这么说,在极少数情况下,全局变量实际上是做某事的“正确”方法。因此,如果您打算使用它,您应该了解理解正确的解决方案。所以你可以在“偷懒”和“写出好的代码”之间做出最好的权衡。

如果你想要做一些全球性的事情,你需要充分理解为什么你这样做。

在这种特殊情况下,听起来你正试图获得在内容。您应该知道,如果您多次请求,ContentManager 将自动返回相同内容对象。因此,不要将模型加载到全局列表中,而是考虑通过 public static 属性使 Game 类的内置 ContentManager 可用>游戏类。

或者,更好的是,有一种我更喜欢的方法,我认为它更好一点: 我在另一个问题的回答中解释了。基本上,您可以在使用它们的类中将内容引用设为 private static 并将 ConentManager 传递到 公共静态 LoadContent 函数。这将静态的使用划分为各个类,而不是使用从整个程序访问的全局变量(以后很难解救)。它还可以在正确的时间正确处理加载内容。

For game development I advocate "Doing The Simplest Thing That Could Possibly Work". That includes using global variables (public static in C#), if that is an easy solution. You can always turn it into something more formal later. The "find all references" tool in Visual Studio makes this really easy.

That being said, there are very few cases where a global variable is actually the "correct" way to do something. So if you are going to use it, you should be aware of and understand the correct solution. So you can make the best tradeoff between "being lazy" and "writing good code".

If you are going to make something global, you need to fully understand why you are doing so.

In this particular case, it sounds like you're trying to trying to get at content. You should be aware that ContentManager will automatically return the same content object if you ask for it multiple times. So rather than loading models into a global list, consider making your Game class's built-in ContentManager available via a public static property on your Game class.

Or, better still, there's a method that I prefer, that I think is a bit better: I explain it in the answer to another question. Basically you make the content references private static in the classes that use them and pass the ConentManager into public static LoadContent functions. This compartmentalises your use of static to individual classes, rather than using a global that is accessed from all over your program (which would be difficult to extricate later). It also correctly handles loading content at the correct time.

静水深流 2024-11-06 02:39:21

我会尽可能避免使用静态,随着时间的推移,你最终会得到意大利面条代码

如果你在构造函数中传递它,你就消除了不必要的依赖,低耦合是好的。依赖项越少越好。

I'd avoid using static as much as possible, over time you'll just end up with spaghetti code.

If you pass it in the constructor you're eliminating an unnecessary dependency, low coupling is good. The fewer dependencies there are, the better.

失退 2024-11-06 02:39:21

我建议实现一个封装模型列表的 Singleon 对象。
查看 MSDN 单例实现

I would suggest to implement a Singleon object which encapsulates the model list.
Have a look at the MSDN singleton implementation.

心房敞 2024-11-06 02:39:21

这是一个平衡和权衡的问题。

当然,OOP 纯粹主义者会说不惜一切代价避免此类全局变量,因为它通过引入任何模块“开箱即用”的东西来破坏代码分隔,从而使其难以维护、更改、调试等

。 ,我个人的经验是,只有当您是一个非常大的企业解决方案团队的一员,维护一个非常大的企业级应用程序时才应该避免它。

对于其他情况,将全局可访问的数据封装到“全局”对象(或静态对象,相同的东西)中可以在很大程度上简化 OOP 编码。

您可以通过编写返回模型列表的全局 GetModels() 函数来获得中间立场。或者使用 DI 自动注入模型列表。

This is a matter of balance and trade-offs.

Of course, OOP purists will say that avoid such global variables at all costs, since it breaks code compartmentization by introducing something that goes "out of the box" for any module, and thus making it hard to maintain, change, debug etc.

However, my personal experience has been that it should be avoided only if you are part of a very large enterprise solutions team, maintaining a very large enterprise-class application.

For others cases, encapsulating globally-accessible data into a "global" object (or a static object, same thing) simplifies OOP coding to a great extent.

You may get the middle-ground by writing a global GetModels() function that returns the list of models. Or use DI to automatically inject the list of models.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文