Instead of shunning List properties, it is smarter to instead get used to them. In most cases they are harmless. In my few years’ of .NET experience, I have yet to run into a problem such as having nefarious code modifying a list when it shouldn’t. I understand the argument against them, but I think it is somewhat academic.

Now I wouldn’t advocate putting a List property in a public API used by a lot of people, but using them in general code is okay in my opinion, especially when you are using XML serialization.

If I were in your shoes, I would eliminate the duplication by removing the redundant interface property types. You haven’t gained anything by putting them in – after all, the lists can still be modified by the other property – and it messes up the code a lot.

Any suggestions on how to remove the duplication?

If I have to calculate the Sum of several order lines or validate the order lines, do the class need to expose its internal state?… not really.

If I have a class that I need to expose to the UI, it does not really matter if it is a T[], IEnumerable, List, IList. Why ? Because the UI need to know the internals of the class in order to render it correctly.

Perhaps your entity is responsible for more than one thing? Both being used by UI, where it is treated as data, and by other classes where it is used as and encapsulated object?

Also when adding the AddXXX and RemoveXXX, you have all but said that your class is some sort of IList, why not implement the interface?

To implement IList, don’t you also need to implement ICollection as well as IEnumerable? That’s about 13 methods. I can think of many scenarios where that is just too much behavior. For instance, inserting and removing elements at specific indexes. This is not only about preventing modifications to collections, but also about encapsulation, and the ISP to some degree.

@Philip – may be there is more behaviour than just inserting into a list when AddWidget, RemoveWidget is called…

That’s what the interfaces are there for, so that you can have complete control of the collection (like you want), but still allow people to use your collection in a standard and natural way.

Personally, If I see a component that forces me to use AddWidget, GetIndex, RemoveWidget, etc., and doesn’t implement IList I wonder if they designed the interface for me (the consumer) or for themselves.

Having read-only objects?? Come on… You must have too much free time.

There is only one framework that tracks all the possible changes: http://www.capableobjects.com/

But that is not my main point. Points are:
1. You just cannot prevent possibility of side-effects only by exposing non-modifable collection.
2. It is bad to expose CLASS, instead INTERFACE should be used. I agrre that all List should be replaced by IList or similar but you cannot use IEnumarable as a guard for protecting collections/objects from modifications.

Cheers.

My collections have changing and changed events (can be cancelled in the case of changing), business logic is handled through configurations that use these events.

As for the entities in the collection being mutable, I was thinking of having using a ‘ReadOnly’ version of an entity that uses aggregation of the entity to expose the state but not any behaviour. These would then be returned as the contents of the collection.

e.g.

public class ReadOnlyOrder
{
private Order _order;

public ReadOnlyOrder(Order order)
{
_order = order;
}

public int Id
{
get { return _order.Id; }
}
}

> “Anyone can effectively add and remove elements from the collection, or even clear them entirely, without your object knowing about it.”
> “I can eliminate the possibility of side-effects in my code due to unexpected externally caused mutations in the state of the collection.”
True. Using IEnumerable you prevent *collection changes*, but there is no way you can prevent *modification of objects themselves*:

customer.ReadOnlyListOfBills.First().Amount = 0; // Still customer is not aware of the change

To prevent this, all the objects must be linked between themselves and subscribed for any possible modifications. This leads to the whole nes set of issues.

So generally speaking you can minimise possible side-effects, but you cannot totally eliminate them.

And yes, the wired thing about exposing IEnumerable is that we have to use Count() extension method to obtain number of elements which is ineffective (as it iterates the collection).

What would you do in this case? Expose a new property:

customer.CountOfBills // returns Count from internal collection

Cheers,
Dmitriy.

I think providing rich API and managing side-effects (which is not hard, using a event-sending or custom collection if really needed) is a sign of better design than limited modification points. Just because in second case it is much easier to forget some useful method and much harder to work with this API in a generic way.

Better would be to not expose a collection at all. If you need to do see then it is time to reconsider the design.