Should you use accessor properties from within the class, or just from outside of the class? [duplicate]

Answer 1

I think its a good idea to always use the accessors. Then if you need any special logic when getting or setting the property, you know that everything is performing that logic.

Can you post the getter and setter for one of these properties? Maybe we can help debug it.

Answer 2

You should always use the accessors, but the function that reads the value from the file (which should be private, and called something like getValueFromFile) should only be called when the value has to be read from the file, and should just read the file and return the value(s). That function might even be better off in another class, dedicated to reading values from your data file.

Answer 3

I have written a getter that opens a file and always regretted it later. Nowdays I would never solve that problem by lazy-constructing through the getter - period. There's the issue of getters with side-effects where people don't expect all kinds of crazy activity to be going on behind the getter. Furthermore you probably have to ensure thread safety, which can further pollute this code. Unit-Testing can also become slightly harder each time you do this.

Explicit construction is a much better solution than all sorts of lazy-init getters. It may be because I'm using DI frameworks that give me all of this as part of the standard usage patterns. I really try to treat construction logic as distinctly as possible and not hide too much, it makes code easier to understand.

Answer 4

No. I don't believe you should, the reason: maintainable code.

I've seen people use properties within the defining class and at first all looks well. Then someone else comes along and adds features to the properties, then someone else comes along and tries to change the class, they don't fully understand the class and all hell breaks loose.

It shouldn't because maintenance teams should fully understand what they are trying to change but they are often looking at a different problem or error and the encapsulated property often escapes them. I've see this a lot and so never use properties internally.

They can also be a performance hog, what should be a simple lookup can turn nasty if someone puts database code in the properties - and I have seen people do that too!

The KISS principle is still valid after all these years...!

Answer 5

I agree with krosenvold, and want to generalize his advice a bit:

Do not use Property getters and setters for expensive operations, like reading a file or accessing the network. Use explicit function calls for the expensive operations.

Generally, users of the class will not expect that a simple property retrieval or assignment may take a lot of time.

This is also recommended in Microsoft's Framework Design Guidelines.;

Do use a method, rather than a property, in the following situations.

The operation is orders of magnitude slower than a field set would be. If you are even considering providing an asynchronous version of an operation to avoid blocking the thread, it is very likely that the operation is too expensive to be a property. In particular, operations that access the network or the file system (other than once for initialization) should most likely be methods, not properties.

Answer 6

I guess what you are trying to implement is some sort of a lazy-loading property, where you load the data only when it is accessed for the first time.

In such a case I would use the following approach to prevent the infinite loop:

private MyData _data = null;

public MyData Data
{
  get
  {
    if (_data == null)
      _data = LoadDataFromFile();
    return _data;
  }
}

private MyData LoadDataFromFile()
{
  // ...
}

In other words:

• don't implement a setter
• always use the property to access the data (never use the field directly)