C# marking member as "do not use"

Question

public class Demo
{
    private List<string> _items;
    private List<string> Items
    {
        get
        {
            if (_items == null)
                _items = ExpensiveOperation();

            return _items;
        }
    }
}

Other methods in the Demo class will have access to the _items field. Since I'm using a property to lazy load the items, I do not want another developer to mistakenly try to use the _items field.

I know there is the ObsoleteAttribute that I may use, but this field isn't technically obsolete.

Is there a better way to mark a member as "do not use"?

Answer 1

Though it's not a general technique for what you want to do (and there isn't one and, as the other answers cover, you need to trust other devs), in this instance, you could create a Lazy<List<T>> (assuming .NET 4 or later - though it's easy to backport)

class Demo {
    readonly Lazy<List<string>> _items;
    public Demo() {
        var _items = new Lazy<List<string>>( ExpensiveOperation);
    }
    List<string> Items { get { return _items.Value; }}
 }

The readonly / non-mutable approach is generally the way to go for backing fields either way.

EDIT: Based on @Timwi's answer (go +1 if you like the idea) one can go to town on it, and in a JavaScript stylee use capability-based restriction to not even expose the Lazy field, just an operation closed over it (Also incorporates @Mr Disappointment's ReadOnlyCollection suggestion):

class Demo {
    readonly Func<ReadOnlyCollection<string>> _getItems;
    public Demo() {
        var items = new Lazy<List<string>>( ExpensiveOperation);
        _getItems = () => items.Value.AsReadOnly();
    }
    ReadOnlyCollection<string> Items { get { return _getItems(); }}
 }

And thus endeth our stupid coding tricks post.

Answer 2

Rename the _items field to _heyFutureDeveloperDoNotReferenceThisFieldMmmkay

Answer 3

If you set such an attribute, then how would the Items getter access it without generating the same warning/error that whatever you're looking for would generate?

What do you mean by "another developer?" If you mean another developer working on this same code (with you), then a simple comment like:

///<summary>Do not access directly, using lazy initialization in getter.</summary>

should suffice, as Visual Studio will show that whenever hovering over the field.

If you mean someone using this class, then that is the whole point of information hiding, and you are good to go.

Answer 4

Yes, there is a relatively simple way. Some might think of it as a hack, but I think it is legitimate. It uses the local-variable scoping rules to achieve the method-level privacy you desire:

public class Demo
{
    private readonly Func<List<string>> _getItems;

    public Demo()
    {
        List<string> items = null;
        _getItems = () =>
        {
            if (items == null)
                items = ExpensiveOperation();
            return items;
        };
    }

    public List<string> Items { get { return _getItems(); } }
}

Now the variable items is correctly scoped to the method that uses it. It is still possible to access _getItems, but doing so is inconsequential because it does exactly the same thing as Items. It is not possible to modify items because it is local or _getItems because it is readonly.

Answer 5

I happen think this is a very valid thing to want to do. Unfortunately, C# wasn't designed with this in mind. So there isn't that much you can really do about it, in practice, in the current version of the language.

If you don't trust the developers on your team, you have bigger problems to worry about.

Strong disagree; if you trust anyone, even yourself, that is when you have a problem. The best code doesn't trust anyone. The best code is bullet-proof. It leaves no way for anyone to screw up.

C# doesn't quite make this possible, though it comes closer than many other languages.

It is private. The buck stops there. If more than one developer works on the private parts of a class then they ought to communicate really well.

Basically the same argument. Yes, it's private, but so what? Why is it not a valid thing to want to encapsulate private details well?

P.S. I've suggested a related (but not quite directly relevant) practical approach to enable better bullet-proofing of code in C# but I don't think many people have seen it. So here goes :) I'd love to see a practical approach for encapsulating private members.

Answer 6

Do absolutely nothing.

With a public or protected member of a well-written class, we would expect accessing it to work in a sensible way and a case where that was not true should be well documented.

With a private field, there's no reason why we would make such an assumption.

Further, if I come to this class as a new developer on the team, I don't know what _items does. What am I going to do with it? There isn't any meaningful job I can do until I've looked at what existing code does with it. And I'm going to see that it's the backing field for a lazy loaded property. All the more so if there's even a tiny bit of documenting comments.

It's not like you can just randomly do whatever you want with other private fields and expect it to work.

Answer 7

How about

private Dictionary<String,Object> PandorasCoochie = new Dictionary<String,Object>()

Then putting your untouchable property backers in there.