请尽量减少使用全局变量来描述你的挣扎 [英] Please Describe Your Struggles with Minimizing Use of Global Variables

问题描述

我写的大多数程序都是相对可流程化的过程，具有明确的开始和希望的结束。问题本身可能很复杂，但不容易倾向于集中使用对象和事件驱动的编程。通常，我只是通过大量不同批次的文本数据来产生不同的文本数据。只是偶尔需要创建一个类：作为一个例子，为了跟踪警告，错误和调试消息，我创建了一个具有一个实例（myErr）的类（Problems），我相信这是一个Singleton设计模式的示例。另一个因素是，我的同事比我更老（程序性），并且不熟悉面向对象的编程，所以我不愿意创造他们无法解决的事情。

然而，我一次又一次地听到，即使Singleton的设计模式真的是反模式，应该避免，因为全局变量不好。

次要函数需要很少的参数传递给它们，并且不需要知道配置（不变）或程序状态（更改） - 我同意。然而，主要控制程序流程的链中间的函数需要大量的配置变量和一些程序状态变量。我相信将一个或多个论点传递给一个函数是一个解决方案，但几乎没有吸引力。当然，我可以将变量压缩到单个哈希/字典/关联数组中，但这看起来像是作弊。

例如，连接到Active Directory以创建一个新帐户，我需要这样的配置变量作为管理用户名，密码，目标OU，一些默认组，一个域等等。我必须通过各种函数来传递这些参数，这些函数甚至不会使用它们，只是通过一个链来洗掉它们，这最终会导致实际需要它们的函数。

我至少会声明配置变量是不变的，以保护它们，但是我最近选择的语言（Python）没有提供简单的方法来做到这一点，尽管食谱确实存在为变通方法。

众多堆栈溢出问题已经触及了原因？坏的和必要的回避，但不要经常提到与这种准宗教限制一起生活的提示​​。你是如何解决全球变量和计划状态问题的，或者至少是和平的？你在哪里做出妥协？除了推动函数的参数外，你还有什么窍门？解析方案

我认为有一段时间和一段时间单身模式的地方，或类似的情况。要记住的关键是一次又一次，当涉及到使用全局/共享/静态变量以及单例模式的错误选择时，许多人都经历了特定的恐惧。

就你而言，你正在专门讨论配置。我认为使用单例风格模式访问这些配置项目并没有什么坏处。每个应用程序都有配置，它应该位于一个你可以调用的位置，不需要传递它，这使得复杂化不仅仅是帮助。

这里的关键是要确保你真的需要信息只存在一次，配置是我发现使用这种类型的模式的最佳理由之一。

Most of the programs I write are relatively flowchartable processes, with a defined start and hoped-for end. The problems themselves can be complex but do not readily lean towards central use of objects and event-driven programming. Often, I am simply churning through great varied batches of text data to produce different text data. Only occasionally do I need to create a class: As an example, to track warnings, errors, and debugging message, I created a class (Problems) with one instantiation (myErr), which I believe to be an example of the Singleton design pattern. As a further factor, my colleagues are more old school (procedural) than I and are unacquainted with object-oriented programming, so I am loath to create things they could not puzzle through.

And yet I hear, again and again, how even the Singleton design pattern is really an anti-pattern and ought to be avoided because Global Variables Are Bad.

Minor functions need few arguments passed to them and have no need to know of configuration (unchanging) or program state (changing) -- I agree. However, the functions in the middle of the chain, which primarily control program flow, have a need for a large number of configuration variables and some program state variables. I believe passing a dozen or more arguments along to a function is a "solution," but hardly an attractive one. I could, of course, cram variables into a single hash/dict/associative array, but that seems like cheating.

For instance, connecting to the Active Directory to make a new account, I need such configuration variables as an administrative username, password, a target OU, some default groups, a domain, etc. I would have to pass those arguments down through a variety of functions which would not even use them, merely shuffle them off down through a chain which would eventually lead to the function that actually needs them.

I would at least declare the configuration variables to be constant, to protect them, but my language of choice these days (Python) provides no simple manner to do this, though recipes do exist as workarounds.

Numerous Stack Overflow questions have hit on the why? of the badness and the requisite shunning, but do not often mention tips on living with this quasi-religious restriction. How have you resolved, or at least made peace with, the issue of global variables and program state? Where have you made compromises? What have your tricks been, aside from shoving around flocks of arguments to functions?

解决方案

I think that there is a time and a place for the singleton pattern, or similar situations. The key point to remember is that time and time again, many people have experienced specific horror when it comes to the "wrong" choice to use global/shared/static variables as well as the singleton pattern.

In your case, you are talking about configuration specifically. I see no harm in using a singleton style pattern for the access to those configuration items. Every application has configuration, it SHOULD be in a location that you can just call, there is no need to just pass it around, that complicates more than it helps.

The key here is to make sure that you TRULY need the information to exist only once, configuration is by far one of the best reasons that I have found to use this type of pattern.

这篇关于请尽量减少使用全局变量来描述你的挣扎的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！