Why static automatic properties is only useful in which the getter is public and setter is private

Question

In book <<c# in depth>>, I have read a sentence "The only scenario in which I can see static automatic properties being useful is where the getter is public and setter is private, and the setter is only called whithin the type initializer". I am not sure what's Jon skeet suggested here.

In my opinion both getter and setter can be used as private or public.

What's the whole sentence? You might have better luck by asking him directly. — Otiel, May 24 '13 at 08:45
Thread safety is what first comes to mind. If you have a public static _automatic_ property setter, then you can create race conditions easily, because the setter is shared among all class instances. — John Willemse, May 24 '13 at 08:46
@JohnWillemse this sentence just claims the scenario of static automatic properties. I know we need extra work to make a setter thread-safe, this should not be applied to static automatic properties only. — ValidfroM, May 24 '13 at 08:51
No, but you cannot make a setter thread-safe if it's an automatic one. — John Willemse, May 24 '13 at 08:52
@otiel is it possible to invite jon skeet to answer that here? Think it should be a good functionality of SO. — ValidfroM, May 24 '13 at 08:53
@JohnWillemse using a lock object when you assign a value? like lock(_lock){staticClass.staticProperty = "balabala"} — ValidfroM, May 24 '13 at 08:56
@ValidfroM: You can find his email on his [profile page](http://stackoverflow.com/users/22656/jon-skeet). Also take a look at his post [here](http://msmvps.com/blogs/jon_skeet/archive/2012/08/22/stack-overflow-and-personal-emails.aspx). — Otiel, May 24 '13 at 09:00
@ValidfroM, and what will you do, if you are accessing this property from various places in your code (which is a common scenario, when it comes to static properties)? How will you share `_lock` field between different classes to synchronize access? — Nikita B, May 24 '13 at 09:04

score 4 · Answer 1 · answered May 25 '13 at 08:11

The point is that static members should generally be thread-safe... and automatically-implemented properties aren't thread-safe, in terms of any guarantee that a value written by one thread will be immediately visible to another. You can't change that within an automatic property, so the only times a static automatic property are useful are:

If you don't care about thread safety
If the setter is private and only set from the static initializer (which is thread-safe automatically). In this case I'd usually just have a readonly static variable and a getter-only property to expose it anyway.

To be honest, settable static properties are pretty unusual (in well-designed code) to start with, even without the thread safety aspect.

score 3 · Accepted Answer · answered May 24 '13 at 09:33

Because auto-properties break encapsulation, which is a basic priciple of OOP. You cannot encapsulate data with auto-properties. The job of encapsulation is to ensure, that your object stays in a consistent state. If you are using auto-properties like this:

public IFoo Foo { get; set; }

you have no option to validate the value in the setter. Setting the property to null is possible without giving you any chance to even notice or forbid it. This may be what you want, but it probably makes it easier to use your interface wrong. This is why the previously mentioned blog-post states

It's a code smell, not an anti-pattern.

You should prefer this style:

public IFoo Foo { get; private set; }

because then you're given the possibility to inject your reference together with the constructor.

public Bar(IFoo foo)
{
    if (foo == null) 
        throw new ArgumentNullException("Foo");

    this.Foo = foo;
}

This makes it easier for clients to use your object the right way. I really suggest reading the previously mentioned blog-post. It describes very well why you should prefer keeping the setter private.

The sentence is about static automatic properties. Your sample is about normal automatic properties. However I agree with your argument. — Peter, May 24 '13 at 09:40
The problems are the same for static and non-static classes. The *static* only limits the number of instances of your class to 1 in this case. However this makes it usually more important to control how data is set. — Carsten, May 24 '13 at 10:06

Why static automatic properties is only useful in which the getter is public and setter is private

2 Answers2