This course is the second course in the specialization about learning how to develop video games using the C# programming language and the Unity game engine on Windows or Mac. Why use C# and Unity instead of some other language and game engine? Well, C# is a really good language for learning how to program and then programming professionally. Also, the Unity game engine is very popular with indie game developers; Unity games were downloaded 16,000,000,000 times in 2016! Finally, C# is one of the programming languages you can use in the Unity environment. This course assumes you have the prerequisite knowledge from the previous course in the specialization. You should make sure you have that knowledge, either by taking that previous course or from personal experience, before tackling this course. The required prerequisite knowledge is listed in the "Who this class is for" section below. Throughout this course you'll continue building your foundational C# and Unity knowledge by exploring more C# and Unity topics and finishing the Unity game you started at the end of the previous course. The material in this and the previous course is essentially our first programming course for Game Design and Development majors at UCCS. Module 1: Learn how we can store lots of data in arrays and lists and use iteration (looping) to repeat actions in your code Module 2: Learn about abstraction and how we can use it to design and implement console application classes Module 3: Learn how we can use abstraction to design and implement Unity classes Module 4: Add text output (like score!) and sound effects to your Unity games Module 5: Complete final peer review “Unity” is a trademark or registered trademark of Unity Technologies or its affiliates in the U.S. and elsewhere. This course is an independent work and is not sponsored by, authorized by, or affiliated with Unity Technologies or its affiliates
Fields and Properties
Loading...
En provenance du cours de University of Colorado System
More C# Programming and Unity
111 notes
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
University of Colorado System
111 notes
Cours 2 sur 5 dans Specialization C# Programming for Unity Game Development
À partir de la leçon
Abstraction and Console App Classes
Rencontrer les enseignants
Dr. Tim "Dr. T" ChamillardAssociate Professor
Computer Science
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.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2019 Coursera Inc. Tous droits réservés.
