Creating an immutable value object in C# - Part V - Using a library

Other posts:

• Part I - Using a class

  • Part II - Making the class bet­ter

    • Part III - Using a struct
    • Part IV - A class with a special value In the last post we presented a variation of implementing a value object using a class. Everything works (obviously), but the amount of code to write is unpleasing. In this post we examine a library based solution. I just describe how to use the Record class, not how it is implemented. You can read the attached implementation code (it is in functional.cs). There is much more in there than Record<>. I’ll talk about the rest in a (hopefully) upcoming series.

    To use the record class you need to in­herit from it, as in:

    public class DateSpan: Record<DateTime, DateTime, bool> {...}

    The generic ar­gu­ment types rep­re­sent the types that com­prise the (immutable) state of the ob­ject. You then need a friendly way for folks to ac­cess this state:

    public DateTime Start { get { return state.Item1; } }
    

  pub­lic DateTime End { get { re­turn state.Item2; } } pub­lic bool HasValue { get { re­turn state.Item3; } }

  This is all you have to do. You don't need to implement Equals, ==, != and GetHashCode. Structural equivalence is given to you by the Record class. Such a property is recursive, in the sense that you can embed value objects inside other value objects and the implementation would walk your object graph as necessary.
  
  For example, given the following class hierarchy:
  
  <pre class="code"><span style="color:rgb(0,0,255);">public</span> <span style="color:rgb(0,0,255);">class</span> <span style="color:rgb(43,145,175);">Order</span>: <span style="color:rgb(43,145,175);">Record</span>&lt;<span style="color:rgb(0,0,255);">string</span>, <span style="color:rgb(0,0,255);">int</span>&gt; {
  <span style="color:rgb(0,0,255);">public</span> Order(<span style="color:rgb(0,0,255);">string</span> item, <span style="color:rgb(0,0,255);">int</span> qty): <span style="color:rgb(0,0,255);">base</span>(item,qty) {}
  <span style="color:rgb(0,0,255);">public</span> <span style="color:rgb(0,0,255);">string</span> Item { <span style="color:rgb(0,0,255);">get</span> { <span style="color:rgb(0,0,255);">return</span> state.Item1;}}
  <span style="color:rgb(0,0,255);">public</span> <span style="color:rgb(0,0,255);">int</span> Quantity { <span style="color:rgb(0,0,255);">get</span> { <span style="color:rgb(0,0,255);">return</span> state.Item2; } }
  

  } pub­lic class Customer: Record<string, IEnumerable<Order>> { pub­lic Customer(string name, IEnumerable<Order> or­ders) : base(name, or­ders) { } pub­lic string Name { get { re­turn state.Item1; } } pub­lic IEnumerable<Order> Orders { get { re­turn state.Item2; } } }

  The following test case succeed:
  
  <pre class="code">[<span style="color:rgb(43,145,175);">TestMethod</span>]
  <span style="color:rgb(0,0,255);">public</span> <span style="color:rgb(0,0,255);">void</span> Record2Test() {
      <span style="color:rgb(0,0,255);">var</span> c1 = <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Customer</span>(<span style="color:rgb(163,21,21);">"Luca"</span>, <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>[] { <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"car"</span>,1), <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"stereo"</span>, 3)});
      <span style="color:rgb(0,0,255);">var</span> c11 = <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Customer</span>(<span style="color:rgb(163,21,21);">"Luca"</span>, <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>[] { <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"car"</span>, 1), <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"stereo"</span>, 3) });
      <span style="color:rgb(0,0,255);">var</span> c2 = <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Customer</span>(<span style="color:rgb(163,21,21);">"Bob"</span>, <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>[] { <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"car"</span>, 1), <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"stereo"</span>, 3) });
      <span style="color:rgb(0,0,255);">var</span> c3 = <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Customer</span>(<span style="color:rgb(163,21,21);">"Bob"</span>, <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>[] { <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"car"</span>, 1), <span style="color:rgb(0,0,255);">new</span> <span style="color:rgb(43,145,175);">Order</span>(<span style="color:rgb(163,21,21);">"stereo"</span>, 2) });
      <span style="color:rgb(43,145,175);">Assert</span>.AreEqual(c1, c11);
      <span style="color:rgb(43,145,175);">Assert</span>.AreNotEqual(c1, c2);
      <span style="color:rgb(43,145,175);">Assert</span>.AreNotEqual(c1, c3);
      <span style="color:rgb(43,145,175);">Assert</span>.AreNotEqual(c2, c3);
  }</pre>
  
  Please don't take my library as production ready code. The amount of test I put into it is limited. You can probably find obvious bugs with it. 
  
  Let's look at other drawbacks. The biggest one is that I'm stealing your base class. If you want your value object to inherit from something else, you cannot. You cannot even have value objects inherit from each other. In that case you are back to implementing your own Equals, == and so on. The only tools at your disposal are interfaces and composition.
  
  Another drawback is that writing classes in this way is slightly unnatural. You have to think about the &#8216;type' of your state in the declaration of the class itself instead of more naturally writing it closer to where you assign names to it (property/field declaration).
  
  Having considered these drawbacks, I'm using this library in all my code wherever I need value objects (which is almost everywhere these days). Writing all the Equals explicitly is too error prone for my taste. I will also be creating IDE snippets for myself that make writing these classes easier.
  
  I don't think I have anything else to say on this topic, so this will be my last post on it. If something else comes up, I'll let you know.
  
  [TimeLineUsingRecord.zip](https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/07/07/77/13/TimeLineUsingRecord.zip)

Tags

• CSHARP

12 Comments

Comments

Geek Lectures - Things geeks s

2008-01-11T14:25:38Z

PingBack from http://​geek­lec­tures.info/​2008/​01/​11/​cre­at­ing-an-im­mutable-value-ob­ject-in-c-part-v-us­ing-a-li­brary/

Community Blogs

2008-01-16T18:44:56Z

For some rea­son, there’s been a lot of buzz lately around im­mutabil­ity in C#. If you’re in­ter­ested in

Charlie Calvert's Community Bl

2008-01-21T01:45:40Z

Welcome to the XXXIX is­sue of Community Convergence. The big news this week is that Microsoft has be­gun

mg

2008-02-01T20:06:12Z

Nice work!
One ques­tion about “stealing” the base class - what about in­tro­duc­ing an­other layer of ab­strac­tion and in­stead of de­clar­ing your type like this:
pub­lic class DateSpan: Record<DateTime, DateTime, bool> {…}
do some­thing like this:
pub­lic class DateSpan: ValueObject<Record<DateTime, DateTime, bool>> {…}
The ValueObject class would then ex­pose the record to as a pro­tected prop­erty and pass Equals, ToString… to the Record ob­ject. It would make the de­c­la­ra­tions a lit­tle bit more com­pli­cated, but your biggest draw­back is not a prob­lem any­more.

lucabol

2008-02-04T12:07:41Z

I think I’m miss­ing some­thing. Aren’t you still steal­ing the base class with the ValueObject class?
I.E. you can­not de­clare DateSpan to in­herit from a MySpan class.

mg

2008-02-04T14:25:00Z

Well, I was think­ing about ValueObject more in terms of a type sys­tem base class, where you can put your ad­di­tional be­hav­iour and not spoil the Record class. You are right that still you can­not have a deeper hi­er­ar­chy of types with this so­lu­tion.
BTW: don’t you think it would be nice to have a lan­guage sup­port for im­mutable types? Something like:
pub­lic read­only class MyClass…
where all fields are read­only fields of read­only types?

lucabol

2008-02-04T14:44:49Z

Yeah, you are right.
We talked about hav­ing first class read­only classes a bunch of times, but we never came up with a pro­posal we are happy with. We are still dis­cussing the topic.

Doekman

2008-02-06T05:25:49Z

Isn’t code gen­er­a­tion a much bet­ter op­tion at this time, while 1st class read­only classes aren’t avail­able?

lucabol

2008-02-06T11:02:03Z

It is an op­tion. I would­n’t say it is bet­ter. It has pros and cons (i.e. read­i­bil­ity, amount of code, man­tain­abil­ity).
As for me, I pre­fer li­brary so­lu­tions to code­gen when­ever avail­able (and roughly us­able).

qq

2008-02-08T16:53:24Z

I think you guys in im­mutable space have frankly lost it. It is not new, it is com­mon prin­ci­ples that do not ap­ply in all fields, and just be­cause func­tional at­tempts are again pop­u­lar you are hit­ting on at­tempt­ing to solve a prob­lem with a wrong tool: .net type sys­tem.
If you think mag­i­cally you will some­how par­al­lelise code and al­go­rithms, you are in for a big ‘immutable sur­prise’.
No, sil­ver, bul­let..

lucabol

2008-02-08T17:32:41Z

All these posts say is: iff you need an im­mutable class, here are a bunch of op­tions of how to do it in C#.
I don’t think I’m claim­ing any­thing more than that. Am I?

Luca Bolognese's WebLog

2008-04-08T17:06:25Z

Previous posts: Part I - Background Tuples are a way for you not to name things. In Object Oriented lan­guages