Which is better implementation or there is no difference?
1.
public class Simple
{
public IList<string> Entries { get; private set; }
public Simple()
{
Entries = new List<string>();
}
}
or 2.
public class Simple
{
private readonly IList<string> entries = new List<string>();
public IList<string> Entries { get { return entries; } }
}
I'll assume that for the second version you meant:
public class Simple
{
private readonly IList<string> entries = new List<string>();
public IList<string> Entries { get { return entries; } }
}
Note that I've made the entries
variable readonly.
If that's what you meant, because you don't need to reassign the variable anywhere in the class (other than possibly in constructors) then I think this is preferable to the automatic property version.
It shows the clear intent that this is meant to be read-only - whereas the automatic property only shows that it's meant to be read-only to the outside world. Someone (perhaps you) might end up changing the value of the automatic property from within the class later on, forgetting that the original design was for this to be a read-only property.
(Of course, we're not really talking about full immutability anyway, as anyone can add or remove entries from the list.)
If you really want to be able to change the property value within the class, definitely use the first version.
Having expressed a preference for the readonly field version, in practice I've found myself using the automatic property because it's less code to read and write. I've felt dirty every time I've done it though. Ideally I'd like a way of creating a readonly automatically implemented property which can only be set in the constructor, just like a readonly field. (The property would be backed by a readonly field, and setter calls would be compiled directly into field assignments.) I haven't heard of any plans for this sort of thing to actually happen though.