Read-only Collection Interfaces5:12 with Jeremy McLain
Use read-only collection interfaces and collection types to control who can alter the collection.
In object-oriented programming, 0:00 the class that uses another class is called the client of the class. 0:02 Don't confuse the term client here with client server or business client. 0:07 A client is simply a class that uses another class in some way. 0:12 We often want to make it so that clients of a class can 0:17 access the items inside of a collection that's stored in the class. 0:20 Let's make a property in the SchoolRoll class that exposes the students list. 0:25 Let's add a property named Students here to return the students list. 0:30 So say public List of student, call it students and 0:35 have the getter return the private students list. 0:41 Students is a read-only property. 0:51 It doesn't have a setter, only a getter. 0:54 All this means is that clients of this class can't 0:57 overwrite the private students field up here. 1:00 However, they can still alter the students list. 1:02 Back here in main, let's add this list of students to the SchoolRoll. 1:05 I've cleared out everything in main except for 1:11 where we're creating the student list and where we're printing it out. 1:13 We'll create an instance of SchoolRoll and 1:17 then add students to it using the addStudents method. 1:21 So say SchoolRoll schoolRoll 1:23 = new SchoolRoll And 1:30 then schoolRoll.AddStudents. 1:38 And then we'll pass in the students list. 1:44 Down here we'll want to change this to 1:49 SchoolRoll.Students, so 1:51 that we're printing out all of the students in the school. 1:59 Having this Students property is great 2:02 because it gives us access to the students. 2:06 But because we've exposed this students list using this property in the SchoolRoll 2:08 class, we can do what ever we want to the students list such as remove the students. 2:13 So we can do something like schoolRoll.Students.RemoveAt(0) or 2:20 we could sort them. 2:29 This could cause problems if the student roll class was reliant on the students 2:39 being in a certain order already. 2:43 Or we could add more students and completely bypass the AddStudent method. 2:46 So we could do something like schoolRoll.Students.AddRange(students):. 2:50 This is dangerous because there might have been some reason why we wanted clients of 3:00 our SchoolRoll class. 3:04 To use the AddStudents method instead of adding them directly to the list 3:05 like this. 3:09 Perhaps the AddStudents method had checked that duplicate students weren't being 3:12 added to the rolls. 3:16 By allowing this type of write access to the student list directly 3:18 via the student property. 3:22 We've created an opportunity for clients of the SchoolRoll class to introduce bugs. 3:23 So what do we do? 3:29 Once again, interfaces can save the day here as well. 3:30 If we only wanted clients of our SchoolRoll class to be able to loop 3:33 through the students, we could change the type of our property here to IEnumerable. 3:37 We can return the student list as an IEnumerable because the list class is 3:48 IEnumerable. 3:53 Since IEnumerable doesn't expose any methods that can 3:56 alter the list in any way. 3:59 This essentially makes the list read only from the point of view of 4:01 the client classes. 4:04 Take a look at the other interfaces that the List class implements. 4:06 You'll notice a number of interfaces that start with IReadOnly. 4:10 IReadOnly collection allows clients to see how many students are in the list using 4:15 the count property and IReadOnly list allows clients to index into the list. 4:19 We could have used either of these collection types as well. 4:25 The purpose of read-only collection interfaces 4:28 is not to provide some level of security against malicious coders, 4:30 the underlying collection here is still a list. 4:34 If we really wanted access to the list again, 4:39 we just need to cast the object returned by the student's property back to a list. 4:42 This is just another form of type encapsulation. 4:47 By exposing the list this way, we are making it clear to other developers 4:50 how we expect the SchoolRoll class to be used. 4:55 You might say that this way our code is self-documenting. 4:58 We should always try to write clear self-documenting code 5:02 in order to help other coders avoid accidentally misusing it. 5:06 This can greatly reduce the chances for bugs. 5:10
You need to sign up for Treehouse in order to download course files.Sign up