Please see the code below:

public class Customer
    private readonly IList<Order> _orders = new List<Order>();

    public FirstName FirstName { get; set; }
    public LastName LastName { get; set; }
    public Province Province { get; set; }
    public IEnumerable<Order> Orders 
        get { foreach (var order in _orders) yield return order; }

    internal void AddOrder(Order order)

Notice that I have removed Primitive Obsession for FirstName; LastName and Province. Notice that I also have a list of Orders, which is returned via an IEnumerable. I asked this question last month: What is the benefit of encapsulating a collection inside a class?

I decided not to encapsulate the list inside an object in the end. However, does this still have the Primitive Obsession smell? I am trying to avoid Primitive Obsession consistently.

Should I be doing:

private readonly OrderList _orders = OrderList();

Instead of:

private readonly IList<Order> _orders = new List<Order>();
  • I don't see any primitives here. I think you mean you're avoiding (not using) primitive obsession. Which is fine since it is a code smell. If so, please edit your question. – candied_orange Jan 26 '18 at 20:52
  • @CandiedOrange, thanks. I have updated my question. Does that help? – w0051977 Jan 26 '18 at 21:14
  • You only fixed 1 of 3 places that have that problem. – candied_orange Jan 26 '18 at 21:17
  • @CandiedOrange, sorry I don't know what you mean. Could you clarify? – w0051977 Jan 26 '18 at 21:19
  • 1
    @Bobson, these classes would contain validation logic. Also if you are going through the code with a Business Analyst or SME, then they understand the concept of FirstNames and ages rather than strings and integers. – w0051977 Jan 28 '18 at 10:24

A collection does not need to be encapsulated inside a class to avoid primitive obsession. Your code example already avoids using primitives throughout.

Had you exposed a collection private IList<String> _emailAddresses = ..., then you would maybe want to consider creating an Email class that eliminated using the built in String type.


First, let’s flip “avoiding primitive obsession” from a negative into the positive we’re trying to achieve, “Strong Typing”.

This means we don’t want to accidentally assign a temperature in Fahrenheit to a variable that’s meant to hold a Celsius temperature.

So, instead of

double temp = 23.2;
double temp2 = 75.7;

//... lots of code

temp2 = temp; //BUG!

We want

Celsius temp = new Celsius(23.2);
Fahrenheit temp2 = new Fahrenheit(75.7);

//... lots of code

temp2 = temp; // Won’t compile. No bug!

Now let’s think for a moment about how we say this signature in English.


We say “IEnumerable of Order”. This type is already strongly typed. We can’t assign an IEnumerable<Customer> to variables of type IEnumerable<Order>. Your code is fine as is.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.