Creating an immutable value object in C# - Part I - Using a class

re: Creating an immutable value object in C# - Part I - Using a class

AlexVB — Thu, 06 Dec 2007 09:13:48 GMT

I am actually a little bit confused but I really belive that classes are reference objects in .NET; so naming "Creating immutable >>value objects<<...." looks a bit freak. Does not it?

So in this case the only thing a developer must do is to properly implement base functionality, i mean base functions available in object class and just protect all the internal data the real object contains.... So the question is what do you really want to write about, new stuff about implementation of base object's functionality that is quite well covered by Rihter and other authors or something new. sorry if i am too rude :) i just really cant get the clue of the article

Creating an immutable value object in C# - Part II - Making the class better

Luca Bolognese's WebLog — Thu, 06 Dec 2007 20:34:12 GMT

Other posts: Part I - Using a class In the previous post I showed how to trivially implement a value

Creating an immutable value object in C# - Part II - Making the class better

Noticias externas — Thu, 06 Dec 2007 20:51:18 GMT

Other posts: Part I - Using a class In the previous post I showed how to trivially implement a value

Brevity vs. Readability :)

Kirill Osenkov — Fri, 07 Dec 2007 23:21:29 GMT

One could probably replace

if ((object)v2 == null)

return true;

else

return false;

with

return (object)v2 == null;

and

if (span.Intersect(other) == other)

return true;

return false;

with

return span.Intersect(other) == other;

Just my 2 cents ;-)

re: Creating an immutable value object in C# - Part I - Using a class

Luca — Mon, 17 Dec 2007 21:07:35 GMT

Yep, one certainly could :)

I have always tended to state the obvious in my code. Once upon a time I thought it to be a bad thing. Now I think it is good.

Maybe I'm just getting old ...

This is standard practice from 1990 in C++ development

Greg — Tue, 18 Dec 2007 20:40:51 GMT

Checklist for locking down an object:

1. Object must be constructed with constructor arguments that initialize all fields. Default constructor is hidden (private). A class factory with a hidden constructor works as well.

2. Assignment operator does a deep copy of the object. Member variables cannot be referred too by more than one object

3. Equality tests both == and != must test member variables and not the object pointer/reference

4. (optional) You cannot get a modifiable reference to the object (C++ only) or a pointer to the object

5. Compound properties, consisting of 2 or more member variables, must be modified all at one time (i.e., may not be modified individually).

6. (Allied Concept) Any data stored by the application must be accessible using stored procedures. Do not access the tables directly.

7. (Allied Concept) Allow multiple copies of the object but have them refer to the same static data (i.e. a single copy of the data usually encapsulated in a static object).

This is standard practice in C++ from 1990 and even earlier than that in ADA and Smalltalk.

It is a good practice, but should be used with restraint because the modularity and/or productivity gains are small for each object using this pattern. Taking modularity higher, such as the business function or major functional module level, usually is more effective.

Generally, over-emphasis on micro-modularity leads to longer development times and systems significantly harder to maintain.

re: Creating an immutable value object in C# - Part I - Using a class

fernando — Mon, 24 Dec 2007 20:38:02 GMT

Immutable values are created as structs in c#, if you set a struct variable to another variable of the same type as in:

struct1 var1 = new struct1(field1, field2);

struct1 var2 = var1;

var2 ends up being a deep copy of var1 stored on a seperate memory location. That's what an immutable type is, if you do that with your class, var2 will be a pointer to the same memory location where var1's value is stored, therefore it is NOT an immutable type.

Incidentally, except for #4, #5 and #6 on Greg's checklist all other checklist items are true characteristics of a .NET structure. 1) Default constructor is hidden and ctor initializes all fields, 2) assignment operator does a deep copy of the object (as I mentioned above), 3) equality tests test the value, not the pointer, and 7) it allows multiple copies of the object but all of them refer to the same data.

Creating an immutable value object in C# - Part III - Using a struct

Luca Bolognese's WebLog — Tue, 25 Dec 2007 01:39:24 GMT

Other posts: Part I - Using a class Part II - Making the class better In Part II I talked about the asymmetry

Creating an immutable value object in C# - Part III - Using a struct

Noticias externas — Tue, 25 Dec 2007 02:01:24 GMT

Other posts: Part I - Using a class Part II - Making the class better In Part II I talked about the asymmetry

Creating an immutable value object in C# - Part IV - A class with a special value

Luca Bolognese's WebLog — Sat, 29 Dec 2007 02:45:33 GMT

Other posts: Part I - Using a class Part II - Making the class better Part III - Using a struct In the

Creating an immutable value object in C# - Part IV - A class with a special value

Noticias externas — Sat, 29 Dec 2007 03:06:18 GMT

Other posts: Part I - Using a class Part II - Making the class better Part III - Using a struct In the

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

Luca Bolognese's WebLog — Fri, 11 Jan 2008 21:36:11 GMT

Other posts: Part I - Using a class Part II - Making the class better Part III - Using a struct Part

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

Noticias externas — Fri, 11 Jan 2008 21:52:04 GMT

Other posts: Part I - Using a class Part II - Making the class better Part III - Using a struct Part

Immutability in C#

Thu, 17 Jan 2008 02:36:52 GMT

For some reason, there's been a lot of buzz lately around immutability in C#. If you're interested in

It's Time for a Change -- We need Immutable Types

brute forced brilliance — Thu, 03 Apr 2008 20:12:58 GMT

It's Time for a Change -- We need Immutable Types

A C# library to write functional code - Part III - Records

Luca Bolognese's WebLog — Mon, 21 Apr 2008 20:35:43 GMT

Previous posts: Part I - Background Part II - Tuples Now that we know what Tuples are, we can start talking

The Quest for Quick-and-Easy Class-Based Immutable Value Objects in C# - Part 1: Introduction

adamjcooper.com/blog — Tue, 03 Jun 2008 22:37:37 GMT

The Quest for Quick-and-Easy Class-Based Immutable Value Objects in C# - Part 1: Introduction

The Quest for Quick-and-Easy Immutable Value Objects in C#

adamjcooper.com/blog — Tue, 03 Jun 2008 23:57:17 GMT

The Quest for Quick-and-Easy Immutable Value Objects in C#