I’m new to C# and .Net in general so this may be a naive thing to ask. But anyway, consider this C# code:
class A { public int Data {get; set;} } class B { public A Aval {get; set;} } The B.Aval property above is returning a reference to its internal A object. As a former C++ programmer, I find this dangerous because by exposing reference to an member object class B violates the principle of data hiding. Nonetheless, this seems to be the normal practice in the C# world.
My question is, if it is at all, why is such a design the usual approach as opposed to returning copies of internal members, which will be much safer in so many ways (including the case of thread safety)?
I understand that even in C++ sometimes good design demands that you do expose class members directly (a Car class with Engine and Stereo objects inside it comes to mind), but it is not the norm as seems to be in C#.
You’re absolutely right – you should only return objects from properties where either the object is immutable, or you’re happy for the caller to modify it to whatever extent they can. A classic example of this is returning collections – often it’s much better to return a read-only wrapper round a collection than to return the ‘real’ collection directly.
On the other hand, pragmatism sometimes calls for just documenting this as ‘please don’t change the returned object’ – particularly when it’s an API which is only used within a company.
Hopefully there’ll be more support for immutability in future versions of C# and .NET, which will make this easier to cope with – but it’s likely to remain a knotty problem in many cases.