在OOP中，为什么全局变量是邪恶的有很多原因。
如果需要共享的对象的数量或大小太大而无法在函数参数中有效传递，通常每个人都建议使用依赖注入而不是全局对象。
但是，在几乎每个人都需要了解某种数据结构的情况下，为什么依赖注入比全局对象更好？
示例（一个简化的示例，以大体上说明这一点，而无需在特定应用程序中深入研究）
许多虚拟车辆具有大量的属性和状态，包括类型，名称，颜色，速度，位置等。许多用户可以对其进行远程控制，并且发生大量事件（用户都可以已启动和自动）可以更改其许多状态或属性。
天真的解决方案是仅将它们制成一个全局容器，例如
vector<Vehicle> vehicles;
可以从任何地方访问。
更加面向OOP的解决方案是让容器成为处理主事件循环的类的成员，并在其构造函数中实例化。每个需要它并且是主线程成员的类都将通过其构造函数中的指针被授予对容器的访问权限。例如，如果外部消息是通过网络连接传入的，则负责解析的类（每个连接一个）将接管，解析器将可以通过指针或引用访问容器。现在，如果解析后的消息导致容器元素发生更改，或者需要容器中的某些数据来执行操作，则无需通过信号和插槽来扔掉成千上万个变量（或更糟的是，将它们存储在解析器中，稍后由调用解析器的人检索）。当然，所有通过依赖注入接收对容器的访问的类都是同一线程的一部分。不同的线程不会直接访问它，但是会执行其工作，然后将信号发送到主线程，并且主线程中的插槽将更新容器。
但是，如果大多数类都可以访问该容器，那么到底它与全局容器有什么不同呢？如果这么多的类需要容器中的数据，那么“依赖注入方式”是否只是伪装的全局变量？
一个答案将是线程安全性：即使我注意不要滥用全局容器，也许将来另一个开发人员在紧迫的最后期限的压力下，仍会在另一个线程中使用全局容器，而不会照顾所有人碰撞情况。但是，即使在依赖注入的情况下，也可能会向在另一个线程中运行的某个人提供指针，从而导致相同的问题。