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

Other posts:

  • Part I – Using a class
  • Part II – Making the class better
  • 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 inherit from it, as in:

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

    The generic argument types represent the types that comprise the (immutable) state of the object. You then need a friendly way for folks to access this state:

        public DateTime Start { get { return state.Item1; } }
    public DateTime End { get { return state.Item2; } }
    public bool HasValue { get { return 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:

        public class Order: Record<string, int> {

    public Order(string item, int qty): base(item,qty) {}

    public string Item { get { return state.Item1;}}
    public int Quantity { get { return state.Item2; } }

    public class Customer: Record<string, IEnumerable<Order>> {

    public Customer(string name, IEnumerable<Order> orders) : base(name, orders) { }

    public string Name { get { return state.Item1; } }
    public IEnumerable<Order> Orders { get { return state.Item2; } }

    The following test case succeed:

    public void Record2Test() {

    var c1 = new Customer(“Luca”, new Order[] { new Order(“car”,1), new Order(“stereo”, 3)});
    var c11 = new Customer(“Luca”, new Order[] { new Order(“car”, 1), new Order(“stereo”, 3) });
    var c2 = new Customer(“Bob”, new Order[] { new Order(“car”, 1), new Order(“stereo”, 3) });
    var c3 = new Customer(“Bob”, new Order[] { new Order(“car”, 1), new Order(“stereo”, 2) });

    Assert.AreEqual(c1, c11);
    Assert.AreNotEqual(c1, c2);
    Assert.AreNotEqual(c1, c3);
    Assert.AreNotEqual(c2, c3);


    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 ‘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.

    Book review: The Halo Effect

    When I read “Built to Last“, “In search of excellent” and “Good to great” I immediately thought: “What a bunch of BS!!”. But again, I think that about most business books.

    The content of these books seemed particularly ludicrous to me. I found both logical inconsistencies and methodological flaws in their process. For example, picking successful companies after the fact is analogous to picking the winners of a lottery and claim that they have exceptional skills. Betting the farm on a single concept (i.e. Big Hairy Goal) is clearly the right thing when you are right, but most often than not you are wrong. What about all the companies that did that and failed? Also, Keeping to the Core worked really well for Coca Cola, but really badly for Kodak.

    These are just examples. These books are packed full of such reasonably sounding absurdities. I thought that everybody would immediately spot this. I thought that the mediocre subsequent performance of the companies originally selected as excellent would obviously demonstrate the unsoundness of such conclusion. I was very wrong. These tomes are hugely successful. People seemed to disagree with me. They really like this stuff. Given that my work and my life were not overly impacted one way or the other, I left the matter to rest.

    And then came “The Halo Effect“. It was a pleasure for me to read, as it confirmed my own ideas (confirmation bias anyone?) and added many more.

    The title is slightly misleading. A better title would have been: “Why the idea of finding common traits among successful companies is baloney”. I know, not as catchy. The catchy halo effect, mentioned in the title, is just the biggest delusion that people have about the topic.

    I found an experiment recounted in the book to be very illuminating. They divided a set of people in multiple groups and gave each group a problem to solve. They then told half of the groups that they did a very good job and the other half that they did a very poor job. The thing is, they did so at random. They then asked people to rate the dynamics of their group on several factors. People that were told that they did a good job reported to have had wonderful dynamics: open discussions, inspired leaders, high caliber people and such. The opposite was true for the other groups.

    It didn’t matter what the actual dynamics had really been: some groups were very confrontational, others were very amicable; some were very vocal, others were very quiet. In the end, people who were told that they did good recalled the experience in positive terms. People who were told that they did poorly, recalled the experience in negative terms. Remember, good and bad outcomes were assigned randomly. Also, the results have been confirmed in several similar studies.

    It is not a good strategy that drives performance. It is perceived performance that makes people think that they had a good strategy. This is: “The halo effect”. This simple concept has dramatic repercussions.

    First of all, it invalidates the main process used in these studies: if you use newspapers articles and managers recollection to draw conclusions, you are just piling halos over halos. People would certainly give all sort of positive attributes to companies that succeeded. They do it exactly because they succeeded. And when these companies fail, they suddenly give all sort of negative attributes to them. The book is full of examples of companies that were rated as excellent when their stock price went up and terrible when their stock price went down. Nothing changed in these companies, they were still doing the same exact thing.

    The book contains many other insights of why these ‘studies’ are deeply flawed. It calls them delusions. You are probably familiar with some of them if you have a scientific background: for example, Delusion of Correlation and Causality, Delusion of Single Explanation (factors are not independent), Delusion of Connecting the Winning Dots (ad hoc after the fact selection). Other delusions are specific to the analyzed domain: Delusion of Lasting Success, Delusion of Absolute Performance, Delusion of Organizational Physics.

    In the end what should managers do? Instead of following these books’s precepts, they should focus on two things: strategy and execution. Both of these things are probabilistic endeavors where the absolutely wrong measuring stick is the result that you obtain. I always found this to be a very common error people fall into at whatever level in an organization. The error is judging the soundness of a decision by its result. A decision should be judged by the soundness of the process to get to the decision and the information available at the time the decision was taken. This is the only thing that is consistent with the probabilistic nature of the world we live in. The book profiles three leaders who embody this probabilistic view.

    In summary, please go and read this book. There are many more things in it than I described in this (albeit long and boring) post.