Monday, September 14, 2009

Early creation of public properties

I’m battling myself a bit about a public API I’m writing. Should I initialize all my public properties in the default constructor, or should I initialize them when accessed?

Having a public property returning null is not an option in my opinion as it leads to extra checking on the consumer of the API. Grunt work which the API should do for you.

Consider the two following classes:

public class MyClass
{
public List<string> List { get; set; }

public MyClass()
{
List = new List<string>();
}
}

and

public class MyClass
{
private List<string> _list;
public List<string> List
{
get
{
if( _list == null )
{
_list = new List<string>();
}
return _list;
}
set { _list = value; }
}

public MyClass()
{
}
}


The pros for the first class is that it’s short and very easy to read. The pros for the second class is that it is more optimized in terms of memory usage if the property is not always used.

My API has an object structure of about 20 classes, which may or may not be set. Some might be used more frequent and favor the first class, as others are infrequent and would favor the last one.

Having both implementations seems a bit inconsistent, so the big question is; should I favor the easy read, or the optimized? If the object structure is being created often, will creating all these extra objects be bad for the clr or doesn’t it matter?

It might be that benchmarking is the way to go to give the final answer, but any comments on the matter is appreciated.

6 comments:

  1. I say, unless performance becomes an actual problem, always go with the shortest, most easy to read version.

    ReplyDelete
  2. That's what I'm thinking as well, so I'll keep the readable version until it becomes a problem or I benchmark my way over to the optimized version.

    ReplyDelete
  3. I would go for the easy to read version as well, but I would suggest a couple of other changes in this particular case:

    - Make it expose the property as an IList rather than List to decouple the concrete list implementation from the public interface.
    - Make the List property readonly; this allow callers to modify the contents of the list, but will not allow them to replace the list with a new one (or null).

    ReplyDelete
  4. Here's another way with Lazy from .Net 4. It's readable, but involves using .Value when using the list.

    public class MyClass
    {
    public readonly Lazy> List = new Lazy>(() => { return new List(); });

    public MyClass()
    {
    }
    }

    ReplyDelete
  5. You could make the lazy version a lot shorter:

    private List<string> _list;
    public List<string> List
    {
    get { return _list ?? (_list = new List<string>()); }
    set { _list = value; }
    }

    ReplyDelete
  6. Good point, but I will most likely stick with my first example with auto property and initializing in the constructor as it's the most readable in my opinion.

    Or maybe just:

    public readonly IList List = new List();

    and skip the property all together. It's very short and readable.

    For my case where I want it initialized, would it be bad practice to have a public readonly variable compared to a property?

    ReplyDelete