(2003 to 2005)


Mon Jul 12 05:28:00 UTC+1000 2004


Collections (or Lists) are interesting.

I think you should probably never store any property value in a collection.

A collection is a list of things of the same type (even if that type is 'Object' (i.e. any type)).

It should be nothing more than that.

If you are modeling a 'set of things in the real world' then create a class to abstract that list, and then give that class a property that is a collection of those things.

You should never have to 'serialize' a collection. You can serialize the 'thing that represents the set of things in the real world' and you can serialize the 'things' but you shouldn't have to persist any other state.

You can still have methods on your collections for working with state in any or all of the 'things'.

I'm not sure what I think of collections and external events, but I tend to suspect that this isn't 'business state' it's 'program state' (i.e. plumbing) so it's probably OK (because it has nothing to do with serialization).

It follows that a collection can never know 'who owns it' or anything like that. (In fact, a collection can know nothing that isn't contained in the list of things that it models).

Did everyone else already know this..? I've sort of realised this before, but I've never 'verbalized' it. (i.e. made it explicit).

This rule will help you manage complexity.


Copyright © 2003-2005 John Elliot