静态变量总体最佳实践

Question

I have a class Meterage which I expect to be instantiated several times, probably in quick succession. Each class will need to know the location of the dropbox folder in the executing machine, and I have code for this.

The class currently has a variable:

private string dropboxPath = string.Empty;

to hold the path, but I am considering making this a static to save repeated execution of

this.LocateDropboxFolder();

in the constructor. But I am a little concerned by the switch: what if two constructors try to set this at the same time? Would this code in the constructor be safe (LocateDropboxFolder becomes static too in this example):

public Meterage()
{
     if (dropboxPath == string.Empty)
     {
         LocateDropboxFolder();
     }
}

I think my concerns are perhaps irrelevant as long as I don't have construction occurring in multiple threads?

Answer 1

If the field is made static then static field initializers or static constructors are the easy way to initialize them. This will be executed at most once in a thread safe manner.

private static string dropboxPath;

static Meterage()
{
    LocateDropboxFolder();
}

If you don't want to re-assign the field I suggest you to use readonly modifier, then the code should look like:

private static readonly string dropboxPath;

static Meterage()
{
     dropboxPath = LocateDropboxFolder();
}

LocateDropboxFolder needs to return a string in this case.

Answer 2

Variables declared outside the constructor are evaluated before the constructor. Then the constructor will evaluate it.

Do remember that you will end up have only one dropBoxPath . If this is intended, it is okay to do so. Optionally, make LocateDropboxFolder a static method and call it from the static constructor.

If you want to prevent other constructors to overwrite the default, try this:

 if (string.IsNullOrEmpty(dropboxPath))
 {
     LocateDropboxFolder();
 }

Or, in a static constructor (at most called once):

static Meterage()
{
     LocateDropboxFolder();
}

private static LocateDropboxFolder()
{
    ...
}

Answer 3

Your example will be safe provided your code is executing synchronously. If multiple instances are created, their constructors will be called in the order they are created.

On the first run through, LocateDropboxFolder() will execute. When this completes, dropboxPath will be set.

On the second constructor execution, LocateDropboxFolder() will not execute because dropboxPath will no longer equal string.Empty (provided 'LocateDropboxFolder()' does not return string.Empty .

However, if LocateDropboxFolder() is asynchronous or the objects are instantiated on different threads, then it is possible to create a second Meterage instance before dropBoxPath has been set by the LocateDropboxFolder() function. As such, multiple calls to the function will likely be made.

If you wish to guard against multithreading errors like this, you could consider using lock statements .

Answer 4

You might potentially end up running the LocateDropboxFolder multiple times if the object tries to be constructed multiple times in close succession from multiple threads. As long as the method returns the same result every time though this shouldn't be a problem since it will still be using the same value.

Additionally if you are setting the value of dropboxPath in the constructor then there is no point setting a default value for it. I'd just declare it (and not assign it) and then check for null in your constructor.

Answer 5

I hava a feeling that your Meterage class is breaking a Single Responsibility Principle. What has the meterage to do with a file access? I would say you have 2 concerns here: your Meterage and, let's say, FolderLocator. the second one should have some property or method like Dropbox which could use lazy evaluation pattern. It should be instantiated once and this single instance can be injected to each Metarage instance.

Maybe not FolderLocator but FileSystem with some more methods than just a single property? Nos sure what you're actually doing. Anyway - make an interface for this. That would allow unit testing without using the actual Dropbox folder.