Is it a good practice to have static variables to store global, changing information?

Question

Is it a good OOP practice to have static variables to store global, changing information needed by different classes?

as opposed to passing parameters around so that it can be accessed by the called classes.

Answer 1

It's not generally a good idea, no... it can definitely simplify some things, but it makes testing harder (and means you can't run tests in parallel, for example).

Some aspects such as logging are typically implemented like this, but I would tend to try not to do it. Dependency injection makes life much simpler in terms of testing. (It can become painful when you need to pass a dependency to class Foo just for that to pass it to Bar, which then passes it to Baz etc. I think we're still not quite "there" in terms of dependency injection. I think something more advanced around scoping/lifecycle would be useful as part of the language, but we'll see... I can't see it happening in C# itself, mind you.)

Answer 2

Apparently you mean Singletons. The answer is: it is not a good idea in general, because it creates difficult to follow dependencies within your code. This in turn makes your code hard to understand, maintain and extend. What's more, it makes unit testing difficult.

If a method is using global objects, you have no way of knowing it other than looking at the source code. However, if the method uses only its parameters and class members, you understand its dependencies by looking at its signature and the enclosing class' definition.

Setting up unit tests for a method which uses global objects is much more difficult than for "normal" methods. Also, there is a risk that someone forgets to reset global state after each test, which results in global state flowing over to other unit tests. This makes your tests secretly depend on execution order, which can produce strange test results.