Immutable read-only objects vs object with automatic properties

Question

I've been wondering about this for a while and haven't been able to find much commentary on the subject and haven't been able to come on a conclusion by myself.

When creating objects, it's accepted best practice to make the object as limited as possible in terms of exposing data and allowing that data to manipulated. If you can make an object immutable, especially in multi-threaded applications, then it is best to do so.

Having said that, C# seems to favor the developer who doesn't follow this rule by allowing the definition of a class to be much more simple, and more importantly, easier to maintain.

Take the following read-only immutable class:

public class ActiveDirectoryUser
{
    private readonly string firstName, lastName, office, username, email;

    public ActiveDirectoryUser(string firstName, string lastName, string office, string username, string email)
    {
        this.firstName = firstName;
        this.lastName = lastName;
        this.office = office;
        this.username = username;
        this.email = email;
    }

    public string FirstName
    {
        get { return firstName; }
    }

    public string LastName
    {
        get { return lastName; }
    }

    ...

    public string Email
    {
        get { return email; }
    }
}

And compare it to the much more simple example as below, which isn't read-only.

public class ActiveDirectoryUser
{
    public string FirstName
    {
        get;
        set;
    }

    public string LastName
    {
        get;
        set;
    }

    ...

    public string Email
    {
        get;
        set;
    }
}

Which can be instantiated with the following is:

ActiveDirectoryUser user = 
    new ActiveDirectoryUser
       { FirstName= "Sam", LastName = "Shiles", ..., Email ="[email protected]" };

Given the simpler definition, the fewer lines of code, the less chance for developer error and the ease with which another developer can understand the code (especially with examples that are more true to life than our simple example), is the value of creating proper read-only, immutable objects, worth the cost?

Also, do other people believe that making immutable objects in C# should be made easier with an automatic-esq syntax such as:

public string FirstName {get; readonly set;}

Answer 1

Given the simpler definition, the fewer lines of code, the less chance for developer error and the ease with which another developer can understand the code (especially with examples that are more true to life than our simple example), is the value of creating proper read-only, immutable objects, worth the cost?

Yes.

I note that nothing is stopping you from saying

int Foo { get; private set; }

and then using the setter only in the constructor, to guarantee immutability of the property. You just don't get the nice object initializer syntax, but you could create a constructor easily enough.

Also, do other people believe that making immutable objects in C# should be made easier with an automatic-esq syntax...

Yes. In particular, the C# language design team believes that.

C# 3.0 added a number of features that make C# a more "immutable-friendly" language: anonymous types, query comprehensions and expression trees in particular encourage an immutable-data "functional" style of programming. It also added features that make C# a more "mutable-friendly" language: automatic properties, object initializers and type-inferred arrays come to mind.

The language design team is well aware that these latter features have made it easier to create mutable objects at the same time as the DLR team was making a huge library of immutable expression tree types. The irony was not lost on them, I can assure you.

There are many proposals floating around the language design team for better syntactic sugars for making immutable objects. The fact that object initializers, which require mutability, have almost identical syntax as anonymous type initializers, which are immutable, is an obvious starting point for exploration, but not the only one.

All that said, of course, first, I no longer speak on behalf of the language design team, and second, there is no announced future version of C# beyond the Roslyn project. Thus, speculation as to possible feature sets for hypothetical future versions of the language is just that: speculation on my part.