我编写的大多数程序都是相对流程图化的过程，有明确的开始和期望的结束。问题本身可能很复杂，但不容易倾向于集中使用对象和事件驱动编程。通常，我只是通过大量不同批次的文本数据来生成不同的文本数据。我只是偶尔需要创建一个类：例如，为了跟踪警告、错误和调试消息，我创建了一个具有一个实例化 (myErr) 的类（问题），我认为这是单例设计模式的一个示例。另一个因素是，我的同事比我更守旧（程序化），并且不熟悉面向对象编程，所以我不愿意创建他们无法理解的东西。
然而我一次又一次地听到，即使单例设计模式实际上也是一种反模式，应该避免，因为全局变量很糟糕。
次要函数需要传递给它们的参数很少，并且不需要知道配置（不变）或程序状态（变化）——我同意。然而，链中间的函数主要控制程序流程，需要大量的配置变量和一些程序状态变量。我相信向一个函数传递十几个或更多参数是一种“解决方案”，但很难说是一个有吸引力的解决方案。当然，我可以将变量塞入单个哈希/字典/关联数组中，但这看起来像是作弊。
例如，连接到 Active Directory 来创建一个新帐户，我需要诸如管理用户名、密码、目标 OU、一些默认组、域等配置变量。我必须通过各种方式传递这些参数甚至不会使用它们的函数，只是将它们通过一条链向下移动，最终导致真正需要它们的函数。
我至少会声明配置变量为常量，以保护它们，但我现在选择的语言（Python）没有提供简单的方法来做到这一点，尽管配方确实作为解决方法存在。
许多 Stack Overflow 问题都涉及到为什么？的坏处和必要的回避，但不经常提及在这种准宗教限制下生活的技巧。您是如何解决或至少解决全局变量和程序状态问题的？你在哪里做出了妥协？除了向函数传递大量参数之外，你还有什么技巧？
我认为单例模式有其存在的时间和地点，或者类似的情况。要记住的关键一点是，很多人一次又一次地经历过“错误”选择使用全局/共享/静态变量以及单例模式时的恐惧。
就您而言，您正在具体讨论配置。我认为使用单例样式模式来访问这些配置项没有什么坏处。每个应用程序都有配置，它应该位于您可以调用的位置，不需要只是传递它，这会使事情变得复杂而不是有帮助。
这里的关键是确保您真正需要的信息仅存在一次，配置是迄今为止我发现使用此类模式的最佳原因之一。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
