如果全局变量有意义？

我拥有许多对象所需的价值。例如，一个以不同投资为对象的金融应用程序，其中大多数需要当前利率。

我希望将我的“金融环境”封装为一个对象，而利率作为一种属性。但是，需要该值的同级对象无法实现。

那么，如何在多个对象之间共享价值却又不会过度耦合我的设计？显然我在想这个错误。

我拥有许多对象所需的价值。

这是设计气味。许多对象需要了解某些事物是很罕见的。也就是说，当前利率是例外情况的一个很好的例子。有一点需要担心的是，有很少的利率。不同的金融工具使用不同的汇率。至少，不同的区域使用不同的“标准”费率。此外，为了帮助测试和报告，您通常希望传递一个费率，因为您不想在那里使用当前费率。您要使用“假设情况”或“截至报告日期”的费率。

那么，如何在不过度耦合设计的情况下在许多对象之间共享价值呢？

通过共享它们，并不是让它们全部都引用一个实例。传递相同的东西仍在一定程度上耦合，但不会过度耦合，因为需要诸如当前利率之类的东西作为各种计算的输入。

在这种情况下，我将使用Singleton模式。FinancialEnvironment将是所有其他类库都知道的对象，但是将由Singleton实例化。理想的情况是，然后将实例化的对象发送到各个类库。

例如：

• 服务层（类库）-通过单例实例化FinancialEnvironment对象
• 业务逻辑层（类库）-从服务层接受FinancialEnvironment对象
• 数据访问层（类库）-接受来自服务层的FinancialEnvironment对象（或取决于您的体系结构的业务逻辑层）。也许Singleton调用数据访问层以从存储库（数据库/ Web服务/ WCF服务）中获取信息，例如利率。
• 实体（或DTO，如果您要称呼它）类库-FinancialEnvironment对象所在的位置。所有其他类库都有对Entities类库的引用。

其他类仅通过Entities类库绑定在一起，它们接受实例化的FinancialEnvironment对象。他们不在乎它是如何创建的，只有服务层在做，他们想要的只是信息。正如@Telastyn指出的那样，根据本地的规则，单例也可以足够聪明地存储几个FinancialEnvironment对象。

附带说明一下，我不是Singleton模式的忠实拥护者，我认为它是一种代码气味，因为它很容易被滥用。但是在某些情况下，您需要它。

更新：

如果绝对要肯定要有一个全局变量，则可以按上述方法实现Singleton Pattern。但是，我不是对此的忠实拥护者，并且根据我原始帖子的评论，其他几个人也不是。就像InterestRate一样易变，Singleton可能不是最佳解决方案。当信息不变时，单例最有效。例如，我在我的一个应用程序中使用了Singleton来实例化性能计数器。因为如果它们确实发生更改，那么您必须具有适当的逻辑来处理要更新的数据。

如果我是一个博彩业者，我敢打赌，利率存储在数据库中的某个位置，或者通过Web服务检索。在这种情况下，建议使用存储库（数据访问层）来检索该信息。为了避免不必要的数据库访问（我不确定利率变化的频率或FinancialInformation类中的其他信息），可以使用缓存。在C＃世界中，Microsoft的缓存应用程序块库运行良好。

与上面的示例唯一不同的是，服务层中需要FinancialInformation的各种类将从数据访问层检索，而不是用Singleton实例化对象。

配置文件？

如果您具有“全局”使用的值，请将它们放在配置文件中。然后，每个系统和子系统都可以引用它并提取所需的密钥，使其成为只读。

我是根据一个人的经验说的，这个人对我们刚刚发布的一个大型（约50k LOC）项目进行了大约一个月的维护。

我可以告诉你，您可能真的不想要全局对象。引入这种残酷行为提供的滥用机会多于它的实际帮助。

我最初的建议是，如果您有几个需要当前利率的不同类，那么您可能只想让它们实现IInterestRateConsumer或即可。在该界面内，您将拥有一个SetCurrentInterestRate(double rate)（或任何有意义的东西），或者仅仅是一个属性。

传递利率实际上并没有耦合-如果您的班级需要利率，那是其API的一部分。仅当您的一个班级开始担心另一个班级如何使用该利率时，这才是耦合。

马丁·福勒（Martin Fowler）的文章简短地谈到了如何将静态全局重构为更灵活的东西。基本上，您将其制作为一个单例，然后修改该单例，以便它支持使用子类覆盖实例的类（并且如果需要，可以将创建实例的逻辑移到可以进行子类化的单独类中，您可以这样做）如果创建超类实例，则稍后将其替换是一个问题）。

当然，您必须权衡单例（甚至是可替代的单例）的问题与将相同对象传递到各处的痛苦。

至于“财务环境”对象-第一次编程很方便，但是完成后，您已经添加了一些额外的依赖项。现在，仅需要利率的类仅在通过金融环境对象时才起作用，这将使它们在您没有碰巧躺在金融环境对象附近时难以重用。因此，我不鼓励广泛通过它。

为什么不将利率数据放在中央缓存中？

您可以使用最适合您需求的几个缓存库之一，诸如memcached之类的东西可以解决所有并发和代码管理问题，并使您的应用程序可以扩展到多个进程。

或全力以赴，并将它们存储在数据库中，这将使您可以扩展到多个服务器。

在这种情况下，我已经成功引入（重复使用）有时会多层的“上下文”一词。

这意味着一个单例，即“全局”对象存储，可以从中请求这些类型的对象。需要它们的代码包括商店的标题，并使用全局函数获取其对象实例（例如现在的利率提供者）。

商店可能是：

• 严格类型化：包括所有服务类型的标头，因此您可以创建类型化访问器，例如InterestRate getCurrentInterestRate（）;。
• 或通用：Object getObject（enum obType）; 并且仅使用新种类（obtypeCurrentInterestRate）扩展obType枚举。

系统越大，后一种解决方案就越有用，因为使用错误枚举的风险很小。另一方面，对于允许前向类型声明的语言，我认为您可以使用类型化访问器而无需在商店中包含所有标头。

还有一点需要注意：您可能具有相同对象类型的多个实例，以用于不同用途，例如有时GUI和打印输出，全局和会话级日志等使用不同的Language值，因此枚举/访问者名称不应反映实际类型，但是所请求实例的角色（CurrentInterestRate）。

在商店实现中，您必须管理上下文级别和上下文实例集合。一个简单的示例是Web服务，其中具有全局上下文（该对象的所有请求的一个实例-在拥有服务器场时有问题），以及每个Web会话的上下文。您还可以为每个用户提供上下文，这些用户可能具有多个并行的会话等。对于多台服务器，您应该为此类事情使用一种分布式缓存。

当请求进入时，您可以确定请求的对象位于哪个上下文级别，并获取该调用的上下文。如果对象在那里，则将其发送回；如果不是，则在该上下文级别创建并存储它，然后将其返回。当然，同步创建部分（并将其发布到分布式缓存）。创建可以是可配置的类似于插件的方式，最好使用允许通过其类名称（Java，Objective C，...）创建对象实例的语言，但是您也可以使用具有工厂功能的可插入库在C中执行此操作。

旁注：调用者不应对自己的上下文以及所请求对象的上下文级别了解太多。原因：1：通过使用这些参数很容易犯错误（或“聪明的把戏”）；2：所请求的上下文级别以后可能会更改。我主要将上下文信息连接到线程，因此对象存储库中的信息没有请求中的额外参数。

另一方面，请求可能包含实例的提示：例如获取特定日期的利率。它应具有相同的“全局”访问权限，但要根据日期使用多个实例（并在费率变化之间将不同的日期值引入同一实例），因此建议向请求添加“提示”对象，实例工厂而不是商店；以及工厂使用的keyForHint。我刚才提到，您可以稍后添加这些功能。

就您的情况而言，这是一种矫（过正（在全局级别上仅提供一个对象），但是对于现在很小而又简单的额外代码，您将获得一种机制，可以满足进一步甚至更复杂的需求。

另一个好消息：如果您使用Java，则无需过多考虑即可从Spring获得此服务，我只是想详细解释一下。

不使用全局（或单例）的原因是，即使您最初希望只具有一个值，但是在同一程序中多次使用相同的代码通常非常有用，例如：

• 计算如果利率不同会发生什么
• 某些成分取决于美国利率，而某些成分取决于英国利率

我将使利率成为“金融工具”类的成员，并接受您必须将其传递给任何成员类（按计算或在构建时为它们指定一个指针/挂钩）。

事物应该通过消息传递，而不是从全局事物读取。