IEnumerable versus List in a concrete class implementation

Question

I am writing a class library for financial modeling.

I want to define the models using interfaces to create abstraction for testing, and the possible later addition of new concrete classes.

I am struggling on how to define lists of things, so I can later add to those lists in the concrete class.

For example, if I define an interface as having a list of expenses in my Model called

IEnumerable Expenses {get; set;}

and later want to create a concrete class called ABCModel with a list of concrete XYZExpense in it, what would be the best way to implement the lists so I can easily add more items to the list?

I cannot cast the List as a IEnumerable.

So for example:

 public interface IFinancialModel
{
    IEnumerable<IExpense> Expenses { get; }
    IEnumerable<IRevenue> Revenue { get; }
    IEnumerable<IAsset> Assets { get; }
    IEnumerable<ILiability> Liabilities { get; }
}

I need a concrete class called public class FinancialModel : IFinancialModel

and be able to add concrete items.

Should I create 'Add' methods of my own? Ideally I would like to leverage built in List functionality and not reinvent the wheel.

Instead of defining them all as IEnumerable, if you want list functionality define them as IList. — Kevin, Sep 12 '16 at 18:21

Stefan Steinegger · Accepted Answer · 2016-09-12T18:27:49.860

It depends on what you actually want to do. Having List or IList properties is not recommended, because you can do everything with it (like Clear, Add and so on) without the owning class know about it. This is not good for encapsulation. You wouldn't be able to do something on change (like setting a dirty flag, fire changed events or do validation).

IEnumerable is a good choice.

You may add setters, but you shouldn't take the value that is set to the property by reference. It could be anything, like a Linq query or even a database query, which you don't want to reference to. You only want the items. (Also consider that the reference to the collection which comes from the outside can be assigned to other instances, which results in very bad side effects when it is changed there but shouldn't be changed here.)

// example implementation with a setter
private List<IExpense> expenses 

public IEnumerable<IExpense> Expenses 
{ 
  get { return expenses; }
  set { expenses = value.ToList(); }
}

Alternatively you may implement your own Add, AddRange, Remove or Clear etc. methods. However, if the main use case is to set all items in one go, you can only have a SetExpenses method, which is the same as the setter on the property I showed before. You may consider to keep it as an array internally.

I will give this a go. Totally agree with your comments in encapsulation. — user3637002, Sep 12 '16 at 19:51
If I wanted to ADD new items to any of the child lists, would I need to write a custom Add method to the Concrete class? Since IEnumerable does not expose an Add() method? — user3637002, Sep 12 '16 at 20:39

score 0 · Answer 2 · answered Sep 12 '16 at 18:24

What you are looking for is IList<T>. This is an interface that allows you to expose the lists while hiding the actual list implementation. For ex:

interface IFinancialModel {
    IList<IExpense> Expenses { get; }
}

Then implement with a list that satisfies your needs. For example:

class FinancialModel : IFinancialModel {
    private IList<IExpense> _expenses = new List<IExpense>();
    IList<IExpense> Expenses { get { return _expenses; } }
}

I agree with @Stefan though, exposing a list breaks encapsulation and should generally be avoided.

IEnumerable versus List in a concrete class implementation

2 Answers2