C# private fields are not accessible outside the class. It’s C# 101 right?
Which means this code should not work…
public class Example { private string _someValue; public void DoSomething(Example otherObject) { _someValue = otherObject._someValue; // What!? You can't access a private variable from another object! Can you? } }
But surprisingly…it does.
As it turns out…
C# Private variables are accessible from other objects of the same type. When you stop and think about it, it’s not as mad as it first seems. Why do we make a variable private? We do it to encapsulate the state of an object. We also do it to maintain control over the state the object.
A simple example could be if we were modelling a container with limited capacity – like a box of chocolates. We could model this like so:
public class Chocolate
{
public string Name { get; set; }
}
public class ChocolateBox
{
public List<Chocolates> { get; set; }
public bool IsValid()
{
return Chocolates.Count < 11;
}
}
Can you spot the problem here?
Even though we have an IsValid method, it’s still possible to add more than the maximum number of chocolates to the box (not that the customer would actually mind).
To prevent this we can encapsulate the box. Then provide methods which enforce our constraints. A nice added extra is that we no longer need the IsValid method.
public class Chocolate
{
public string Name { get; set; }
}
public class ChocolateBox
{
private List<Chocolate> _chocolates;
public void AddChocolate(Chocolate chocolate)
{
if(_chocolates == null) _chocolates = new List<Chocolate>();
if(_chocolates.Count == 10) throw new Exception("No more space");
_chocolates.Add(chocolate);
}
// Other methods removed for brevity
}
The assumption here is…
You cannot expect developers who are building other parts of the system to know how your thing (box in this case) works.
Good tests, whether they be unit or integration will help here. The real value is, to avoid misunderstandings in your code by making the implicit, explicit.
But if the developer is working within the class then they should know how the class works. You can then trust them to change the internal state – even of other objects of the same type!
I’m sure there are other good reasons why this quirk exists (if you know one add it to the comments). But I want to highlight one use which I’ve found particularly handy.
Access to C# Private Variables is Handy When Building Value Objects (VO)
One of the tactical patterns in Domain-Driven Design is the Value Object (VO). By the way you don’t need to be doing DDD to use it. It’s defining feature is that it’s equatable by its value rather than by id.
A common example is a string. If I create two strings with the same characters in the same order and the same case then they are equal to each other by value.
Another example could be a ‘telephone number’ in a CRM. One number is equal to another by value. Unless you happen to be writing software for a telephone company. In which case the telephone number could potentially be the customer id and therefore not a VO.
More often than not a VO is immutable. That is, once it’s created you can’t change its value. This is the case for our string example. When you ‘change’ a string you are actually creating a new object.
Back to the point. Why is it helpful to be immutable?
I can think of 4 reasons:
- It’s much easier to test an object which can’t change
- It’s easier to parallelise an immutable object
- It’s easier to ensure it is always in a valid state
- You don’t need to keep track of many id’s in your application *
* is probably the biggest reason.
How To Use C# Private Variables When Building Value Objects
To illustrate a value object lets model a fluid container – otherwise known in our domain as a cup.
Each cup has a maximum capacity of 1ltr. We can decant the content of 1 cup into another*. Any liquid over the max volume is lost. A cup is considered equal to another cup depending on the volume of liquid it contains.
* from a code perspective, this results in another instance of a cup.
CODE KATA: Hone your coding skills with this 'Colour Mixer Code Kata' download. Click here to download.
Let’s start with some tests…
How do we construct a cup? Because we want to make our cup immutable let’s pass in the current volume of liquid into the constructor. So our first rather simplistic test could be to ensure we can construct a cup with a volume of liquid.
[Test]
public void Constructor_ValidVolume_ObjectIsNotNull()
{
var cup = new Cup(0.5m);
Assert.NotNull(cup);
}
// Now let’s ensure we cannot create a cup containing an invalid volume, e.g. more than a litre or less than 0 litres.
[TestCase(-0.1)]
[TestCase(1.1)]
public void Constructor_InvalidVolumes_ThrowsException(decimal invalidVolume)
{
ArgumentOutOfRangeException expected = new ArgumentOutOfRangeException("volume");
ArgumentOutOfRangeException actual = null;
try
{
var cup = new Cup(invalidVolume);
} catch (ArgumentOutOfRangeException ex)
{
actual = ex;
}
Assert.AreEqual(expected.ParamName, actual.ParamName);
}
Now we can get to the interesting part.
How do we ensure they are equal?
This is where we can take advantage of access to C# private fields.
[Test]
public void Equals_TwoEqualCups_AreEqual()
{
var cup1 = new Cup(0.5m);
var cup2 = new Cup(0.5m);
Assert.AreEqual(cup1, cup2);
}
I’ll leave the ‘Decant’ method as an exercise for you. Interesting question though, what happens to the cup when you decant the liquid out of it? It is after all immutable 😉
Conclusion
Value Objects are a useful construct in Domain-Driven Design. When overriding the equals method, you can take advantage of this ‘quirk’ in C#. The quirk is you can access private variables of another class of the same type.
I hope you found this little tip handy. Leave a comment and let me know.
P.S. I’ve created a code kata based designed to be used to illustrate VO’s. It works well as a team exercise. Download it here:
CODE CHALLENGE: Hone your coding skills with this 'Colour Mixer Code Kata' download. Click here to download.
Equality check is a good point, without this “feature” overriding Equals would easily turn into a painful task.
BTW. This exact privacy “feature” is described in Bart De Smet’s “C# Unleashed” – great book, highly recommended.
Thanks for the recommendation.
[…] Why Private C# Variables are Not as Private as you Thought (Daniel Whittaker) […]
Good read and a nice little feature!
Regardin “Unless you happen to be writing software for a telephone company. In which case the telephone number could potentially be the customer id and therefore not a VO.” I disagree. In this scenario, the customer is an entity and not a value object, but the ID of the customer itself should always be a value object. The ID cannot change, so it is immutable, and as such also equatable to other ID:s. It’s actually quite good convention to explicitly create separate ID classes to represent the ID:s of other entities, as then changing the ID or managing the equality is easy.
Ah – my mistake, it was supposed to read ‘line id’ as in the specific telephone line. But you make an interesting point nonetheless.
I think you have a major recurrent flaw in this post. You meant private FIELD, not variable.
I wouldn’t doubt you could access variables from another method… somehow… I was actually interested in seeing that happen here. You really need to edit your post ctrl+f variable and replace with field pretty much.
I’m not sure it’s ‘major’ but annoyingly I think you’re right. Any chance you could prroof read my next post – before I publish it 🙂
Sure, ping me on twitter or chris a† marisic do† com when you want me to look over something
[…] Why Private C# Variables are Not as Private as you Thought – Daniel Whittaker […]
The overall idea with this feature comes from C++. For example, copy constructors in C++ need to have access to private fields in order to deep copy the object. Your example with overriding the Equals method is also a good justification for this feature to exist.
Yes that makes sense. Thanks.
“from other classes of the same type” – can you give me an example of two different classes with same CLR type?
Corrected – that should read “objects of the same type”. I don’t think it works with inherited types.
This is similar in concept to making a static factory method on a class. The factory method can still do what is necessary to create an instance. You might have some more complex logic that you only want at creation time and you want to prevent a public creation to make it obvious that this complex logic might exist (or you want to then create a singleton using a private static variable). Anything defined within the class has access to the properties/methods within the class and any instances of that class.
public class TestObject
{
private currentTime DateTime;
private TestObject() {}
public static TestObject CreateInstance()
{
var obj = new TestObject();
obj.currentTime = DateTime.Now;
return obj;
}
private static TestObject singleton;
public static TestObject GetSingletonInstance()
{
if(singleton == null)
singleton = CreateInstance();
return singleton;
}
}
The “quirk” exists to enable certain performance optimizations. Being able to look inside other objects internals will in general allow for certain operations to be carried out faster than when you need to go through its public interface. It’s at the heart of the difference between Abstract Data Types and objects, see for example http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf.
Nice find – thanks
[…] Adventures in String Concatenation: Introducing String Interpolation – Rion Williams() Why Private C# Variables are Not as Private as you Thought – Daniel Whittaker Null Object Pattern – (DevIQ) Using Lazy and […]
Could you fix sample code encoding html entities, please?
Sorry about that. It seems I have an issue sitewide. They should be fixed here now.