Looking at Phil Haack's article on Thread Safe collections brought up a common theme. Do we trust our fellow developers?
From http://haacked.com/archive/2007/03/25/thread-safety-via-read-only-collections.aspx
The design of this class does not express the intent that this collection is meant to be read-only.
So why would we ever build a read-only class. Surely the only reason for this is that we don't trust the next person to use the code to use it correctly. I've racked my brains to try and come up with a similar metaphor using the common architectural analogies, but I can't find one. When do (engineering) architects ever specify that you can only use something in one way? They don't, but they do give a list of specifications that let you decide. e.g.
Tensile strength of 440Nms means that you can only run this span over 1.3Kms
You build a 2Km bridge span with that component and whoops.
However a bigger question is should we be restricting the users of our class in this way. Who knows more, us now, or the future developers? So we wish to empower the users of our class with the ability to change things, so they can respond to actions outside of our control or simply lock them in so that we maintain control. What happens when
Alaska splits into 50th and 51st State in battle over correct names for snow
I think the fact that we want to do this, is actually more revealing of our attitude to our fellow developers and their abilities, and its something I constantly battle with. A few years ago, two software teams were merged, one team had been working on a three tier windows application that used diverse technologies such as remoting, OfficePIA hosted in Excel, and a custom WinForms GUI. The other team used ASP.Net, and read from a database. One particular developer was newer and less confident and also very shy and quiet. I made the mistake of allowing for this developer's inexperience and attempted to develop a code interface that would ensure you only ever dealt with one object for the same data. i.e. If Pass the same parameters to the same interface and you get the same object back, rather than two objects with the same data.
The reason I thought I did this was because I wanted to consistency of objects.These days I wonder if I simply wanted to micro-manage and ensure control. I wanted to direct (see http://www.martinfowler.com/bliki/SoftwareDevelopmentAttitude.html) the developer to use my language correctly, and not enable them to do it themselves correctly.