In this lecture, we'll implement the fields and properties for our Die class. So, this is all about the state of a Die object. We're storing the state and fields and we're providing access to the state through the properties. Here on the UML diagram, you can see I've circled where the rectangle, the fields and properties that we're implementing. We'll start implementing our Die class by implementing the fields and properties. And this is the console app project that I created in MonoDevelop but I haven't added the Die class yet because I wanted to show you how to do that. Over here in the solution pane, we'll right click the project name which is this bold faced DieExample and I'm going to say, Add a New File. And by default, my new file is an EmptyClass. I'm going to change the name of that EmptyClass to Die and I'll click New. As you can see, we get a new template for our Die class so I'll add a documentation comment and MonoDevelop automatically gives us a no-parameter constructor. I'm going to get rid of that and we'll add our own constructor later. So, we're going to start with fields and properties, I'm going to mark a region as Fields. And remember, this region markup is just for within our IDE, it's got nothing to do with the actual code that gets compiled. And as our design showed, we need two fields. We needed numSides, which is an int, and we need topSide, which is also an int. So, something we haven't talked about yet because we actually haven't developed our own class yet, is we can actually provide different levels of access to each of these fields. For example, I could make this numSides field public and that would mean that any other class in my application can directly access numSides. That is a horrible idea. It lets any other class dig right into the innards of our class and access the field, and so we don't want to do it. What we really want is private. And because that is the appropriate way to implement information hiding, by default, if we don't put any word in front of the data type, then it is, by default, private. The keyword that we put in front of variables to control access to those variables is called an access modifier. Now, you should go do an in-video quiz about that terminology. Okay, so we've declared the variables for our fields, now let's implement our properties. And again, I'll mark our region, and this is for readability, this is not required, your code doesn't have to have regions. Almost all the code that I write does have regions. Okay, so here's how properties work. Remember, properties are the way that we let external classes access information about the state of this particular object. If we're going to let them do that, then we'll make our property public. This isn't the same as making our field public because we have control through our properties what they can do and what they can't do. The property for numSides will have int as a data type and then we give the property name. And I'm going to use capital N because we will start our property names with capital letters just as we start our class names with capital letters. And now, I'll show you the two different things that we can do in properties. One of which is perfectly appropriate for NumSides, and one of which is absolutely inappropriate for NumSides, so I'll get rid of it as soon as I've implemented it just to show you how it works. So, properties, we can read them. We can write to them to change the property, and we can both read and write. So, I'm going to do both read and write. So reading, we implement something called a get accessor and to write the property, we implement something called a set accessor. For the get accessor, we know that if someone's asking how many sides this Die has, that that number is stored in the NumSides field. So, we're going to want to do something with the value of the NumSides field and by putting the name of the variable, we are accessing the value, just as we've seen if we do math with these things, and so on. That doesn't actually finish the get accessor though because we also need to not just retrieve this value from the variable but we need to return it to whoever is accessing the get accessor. Programmers are sometimes really crazy with their terminology but this isn't one of those times because to return something, we type, return, and that implements the get accessor for the property. The set accessor lets somebody set the property and so, typically here, we would set numSides equal to something and the something that we would set it equal to is a special keyword called value. When we actually start setting values, accessing the set accessor for properties, I'll show you the syntax for doing it. But really, value is typically something that appears on the right hand side of an equals just as though we're doing an assignment, and the value gets passed in here and we can set numSides equal to that value. So, if you'd like to think of value as sort of a special form of argument that we pass on to the set accessor for the NumSides property, that's a reasonable way to think about this process. Now, let's talk about which of these accessors is crazy. Letting someone find out how many sides the Die has is perfectly reasonable. After the Die has been created, letting someone change the number of sides on the Die is not reasonable. That would be like if you were playing a dice game and you let somebody pick up a die and shave it down with a file to add an additional face and then mark it up with a magic marker or something, that would be what this would support. And there's a word for that, let me think, it's called cheating. So, we won't let that happen. I will get rid of the set accessor for this property, we'll only let consumers of the class access the get accessor to find out how many sides the Die has without changing them. Now, I'll add a comment, Gets the number of sides, and I'll just edit this a little bit like so. Almost identical arguments go along with the topSide property that we'll implement. I will change this to say top side, this will be top side here. It will, of course, be an integer again, and we'll return topSide. So, you should be able to understand why we don't provide a set accessor for this either. It is also cheating in a dice game to roll the dice and decide that you want to change one of the dice, and so you reach over and you spin the die until it has the top side you want and you put it back down. If you don't believe me that this is considered cheating, you should make a trip to Las Vegas and go to the craps tables and try it out and see how the casino responds, and it will be an interesting response, it will be a life experience for you. Okay, really what I ought to do at this point is I should create a Die object and test the NumSides and TopSide properties. Unfortunately, I got rid of that constructor because I want to write my own in the next lecture so we can't really do that testing at this point. To recap, in this lecture, we implemented our own fields and properties in our Die class. We learned about access modifiers and how we can use them to control visibility into our fields and our properties. We learned about get accessors for reading properties and we learned about set accessors for writing properties.
