I heard someone ask a question about encapsulated collections today and pointed to this blog post http://www.lostechies.com/blogs/jimmy_bogard/archive/2010/03/10/strengthening-your-domain-encapsulated-collections.aspx
I don’t want to comment on the blog post exactly, but I do want to comment on encapsulating collections in general. I’ve struggled with it. For some reason the OO purist in me wants to strong type everything and when it comes down to collections a Collection<T> or List<T> just isn’t good enough. I want to go full FDGL and make MyTypeCollection that extends Collection<T> or implements IList<T> or something of the sort and have all sorts of nice checking and expose only what is needed on MyOtherTypeThatHasACollectionOfMyType.
But what value does this add?
None.
Zero.
Zilch.
Nada.
My years of PHP and Perl before finding the joys of strong and static types taught me that you just use what is at your disposal and you don’t worry about bugs that don’t exist yet. No one (that I ever saw) ever wrote collection types in these languages. We always just used the built in lists and arrays. If an API didn’t support you adding to a list at the wrong time, then things didn’t work and you would read the docs and/or source and find out just what was supported and what was not. I’m guessing things are this way in the Ruby and Python world too.
The idea that encapsulation is good came about because programmers were creating the same bugs over and over again and running into the same problems again and again. These were the bugs and problems that encapsulation could solve. Do you really think a django or rails programmer is going to go make sure that a controller or other consumer of a model cannot accidentally clear a collection of values on that model? Or add to it when the model thinks that it should not be added to? No. Its a waste of time to do these things before it becomes an issue. Its premature optimization to fix a bug that doesn’t exist yet. If you try, you are just writing code for no reason.
Its probably not important to spend hours or days writing it when you can just as easily document it and say "don’t do that." If you have team members who don’t read documentation, you have bigger problems. Better yet, make everyone on the team aware of the code. Work in a shared ownership environment. Solve problems of unintended use by working with people rather than creating extra work to prevent unintended use.
I’m tempted to make some "the state of this collection can never be invalid" types too. Lets promise each other that we won’t spend time on this. Lets solve better problems.