Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

C# Entity Framework Basics Extending Our Entity Data Model Adding a One-to-Many Entity Relationship

Setting a property in the constructor

I understand that we're using an interface for the navigation property to avoid tying ourselves to a concrete implementation...kind of.

My experience with interfaces is that they give us flexibility by giving us the option to pass a variety of objects that implement that interface.

My question: by immediately setting the navigation property to List<T> in the constructor, doesn't that defeat the purpose of the interface? At what point, in practice, would we ever have the opportunity to use a different type that uses ICollection<T>? I could understand if we passed some type of object that implements ICollection to the constructor...like maybe we could pass an array, list, enumerable, etc to instantiate the object and set the navigation property, but we don't. We immediately set it to List<ComicBook>. Why not just use List<T> in the navigation property if we're going to instantiate it that way every time?

Thanks a bunch!

1 Answer

Alexander Nikiforov
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,175 Points

I actually come from Java, so that may be not really right, but I try my best.

Yes ICollection is an interface. But we cannot write

// wrong, won't work
public Series {
ComicBooks = new ICollection<ComicBook>()
}

That won't work. Because for every interface we have to provide implementation in the end.

In the way he wrote his code we want to say roughly: "Hey I know that in the end we will use List<ComicBook>, but because we define this List through ICollection, List cannot use his own methods, he can use only methods that are in ICollection"

We can say that List is implemented through interface. It is very common technique in OOP.

BUT if you decide to

Why not just use List<T> in the navigation property if we're going to instantiate it that way every time?

Then you cannot switch to new implementation by changing one line, because it can happen that some methods that are in List they are no longer in LinkedList

PS

There are ton of resources out there, try googling.

Here is one of the examples

http://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface

And one more note

It is does not matter what we use in Constructor since we will be using ONLY methods of an interface and not the concrete implementations. In the reality we instantiate ICollection in constructor so that later we don't have NullPointerException, but always have empty Collection. This is important for Database. I think.

And like I sais before later on if you decide to switch to LinkedList. It is very common.

You can just say

            ICollection<ComicBook> books = Series.ComicBooks;
            List<ComicBook> list = new List<string>(books);
            LinkedList<ComicBook> linkedList = new LinkedList<string>(books);

This should be valid code, or at least concept, i didn't check syntax.

That means EVERY time you ask for ComicBooks from Series, you get ICollection. You never get List That is why we have flexibility.

If we define List<ComicBook> then it won't work.

Alexander, thank you for your detailed response. Your last point is what I was confused about. Thank you so much!

Kevin Gates
Kevin Gates
15,052 Points

Very well written and explained. Thanks!