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

Is it a good OOP pr开发者_开发知识库actice 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.

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.)

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.

static variable are generally used to represent fixed value with final like

public final static String JANUARY="january";

As per my observation, since the static members are initialized only once, there will be no over head of re-allocation of memory, each time the member is accessed.

However it won't be a good OOP.

The danger with this approach sometimes is, you may get some unexpected results if somebody is trying to access and modify the properties in wrong.

But for private methods or methods called from several places for the purpose of same functionality, it will be a good practice to keep the methods static, and the same is advised by FxCop too.

Who owns the information? usually it would be best to wrap the information into the class that owns it, and have it accessed through static functions of that class, I believe.

This also makes it easier to address the issue of multi-threaded access, as you can put the synchrionisation mechanisms into those functions to control access.

The use of static variables introduces complexity to multi-threaded applications and so is generally not considered to be a good idea. Wrapping such data in singleton classes allows you to setup a suitable locking mechanism to govern access to the shared data.

I think better practice is to use *.properties files which contains all configurable parameters. Also you can implement singletone-like class *Configurator which will load all parameters into your application.

There is a lot of open source libraries which can help you manage application parameters. In case of Java: http://commons.apache.org/configuration/index.html

No, try to have as much as loose coupling as possible. If you want your code to perform as individually cohesive entities, then sharing global information using static variables is highly not recommended. Yet, you can constant values with them. But then, Enums are there in Java. So, I would recommend not to use them.

Combining them in some sorts of Properties classes and implementing them as Singletons would be an acceptable OOP practice.