Refactoring Day 1 : Encapsulate Collection

In certain scenarios it is beneficial to not expose a full collection to consumers of a class. Some of these circumstances is when there is additional logic associated with adding/removing items from a collection. Because of this reason, it is a good idea to only expose the collection as something you can iterate over without modifying the collection. Let’s take a look at some code

   1: public class Order
   2: {
   3:     private List<OrderLine> _orderLines;
   5:     public IEnumerable<OrderLine> OrderLines
   6:     {
   7:         get { return _orderLines; }
   8:     }
  10:     public void AddOrderLine(OrderLine orderLine)
  11:     {
  12:         _orderTotal += orderLine.Total;
  13:         _orderLines.Add(orderLine);
  14:     }
  16:     public void RemoveOrderLine(OrderLine orderLine)
  17:     {
  18:         orderLine = _orderLines.Find(o => o == orderLine);
  19:         if (orderLine == null) return;
  21:         _orderTotal -= orderLine.Total
  22:         _orderLines.Remove(orderLine);
  23:     }
  24: }


As you can see, we have encapsulated the collection as to not expose the Add/Remove methods to consumers of this class. There is some other types in the .Net framework that will produce different behavior for encapsulating a collection such as ReadOnlyCollection but they do have different caveats with each. This is a very straightforward refactoring and one worth noting. Using this can ensure that consumers do not mis-use your collection and introduce bugs into the code.


This is Day 1 of the 31 Days of Refactoring. For a full list of Refactorings please see the original introductory post.

31 Days of Refactoring