A mini challenge for you… how would you describe an interface in C#? What could you use it for?
Any other talk of questions? Please create a new post.
A mini challenge for you… how would you describe an interface in C#? What could you use it for?
Any other talk of questions? Please create a new post.
I could use “If” for an if statement, such as; if (this == true) return;
Not sure I follow.
Interface is a characteristic to be given to the class. Regular class Inheritance is what the object is and Interface inheritance is an addition to what it can do. For example, the whole IPointer interface “family” is there to allow the class to receive further information from interactions with the cursor, it’s an additional characteristic but isn’t what define the object. Another example is IDamageable, usually created in order to handle damage across multiple different objects.
To keep it simple, it is a contract. Even though the syntax is similar, it is not an inheritance. A class can implement an interface, meaning that is has to implement the functions with the signature that the interface requires it to implement. It can be a very powerful thing to use when you want to avoid inheritance and still assure that certain functionalities are given on a range of classes. The specific definition of the contracted functions can vary across all the classes that implement the same interface, while type, name and parameters will be the same. Therefore it can be great to use to reduce strict dependencies. If I have a function that requires a certain object but I don’t know yet what class that specific object is I can simply use an interface to ship around this problem.
I was attemptingToBeClever but I failed
you wrote that as a second question but I believe you may have meant “it”.
I’ve corrected it so now no one will understand
I would say that IDamageable is part of what the class that implements it does. It’s a way of segregating the responsibilities I guess. However, it can never have functionality which makes it less like a characteristic. In other languages, you can use multiple inheritance or mixins for this.
Yes, I guess that it’s more accurate to say that it’s a way of segragating the responsabilities rather than a characteristic.
I just wanted to say that this and the last lecture alone are worth 10x the price of this course. The revelations in it are amazing not just for game programming but for OOP. I never really got or saw the point to interfaces even after hours reading books but in two lessons here you explained it so well, especially in the context of layered dependency flow charts. So a special thanks for that.
Here’s my copy/paste from notepad of what I think an interface is now
An interface is a “contract” between the parent and child type. Any child using the interface must implement the member signatures of the interface. The parent now doesn’t need to know about nor depend upon any of its children, only the interface that the children agree to implement. Now the parent can behave as if it had access to the children even though it doesn’t, because the children agree to implement the interface. No dependency exists between parent => child, only child => parent. An object can implement multiple interfaces. An interface can inherit from multiple other interfaces (ie: requiring their member signatures for any object implementing that interface).
I have had a difficult time understanding the interface thing, I understand it on a theoretically level, like with the zoo analogy. It makes sense, but in this practice its still a little bugger. So I came up with my own little analogy that only works for this case.
A lazy no-good dad sits on the pouch reading the paper, he has his 2 children doing chores in the garden. One is mowing the lawn, the other is trimming the hedges.
The child mowing the lawn yells at his dad “Look dad, I’m mowing the lawn”. Barely looking up from his paper he responds: ”That’s fine. “Return” to your choirs”
After a short while the other son comes up to his father: “Look father, I’m done”. The dad waves his hand at his son “Go talk to your mother what to do next”
The son asks his mother “Mom, I’m done trimming the hedges, what now?” “Go “cancel” your chores by cleaning up”. The son puts the shears in the shed.
Meanwhile, the other son has finished his chores, and approaches his father, that sends him to his mother, who replies: “Go “cancel” your chores by cleaning up”. The son pus the lawn mover in the garage.
It makes sense to me, I hope it helps someone else
Interfaces were hard for me to grasp so I will try to help anyone who struggled like me. I do not believe I fully understand them yet but I hope I can explain what I do understand in a way that may help anyone struggling.
To me interfaces are like tags. we create a tag but have instructions on it that the tag can only be pinned onto a class with certain properties or methods/functions.
Looking at how Sam used them in this lecture, we have a class called ActionScheduler. This class has a single method called StarAction in which we give it an action when we call it. What is an action? It’s just the word sam used but in this case it is a class tagged with IAction. So far when any other class calls StartAction they have to provide a class with the IAction tag (AKA interface).
The method StartAction then performs the following:
When Mover.cs calls StartAction when it starts moving we provide the class (this) meaning itself into the method.
When Mover.cs calls StartAction it checks to see if mover called it last, if so it returns since we didnt actually start anything new we are continuing what weve been doing.
If mover wasn’t the last class to call StartAction then it continues and checks to see if this method has been called before. If it hasnt, then StartAction sets mover as the current class/(“action”) and ends. If it was called previously by another class then it calls that other class’ Cancel() (fighter’s cancel) function and then names itself as the current class/action (next time it is called the mover will be the previous class to use it).
In the above paragraph when Cancel is called by fighter it sets the target to null which makes it stop moving and attacking.
The other way around if Fighter calls the action when it starts attacking it provides itself and then cancels then calls the Movers Cancel() method which tells it’s navmeshagent to stop, therefore stopping it’s current movement.
Using IAction as an interface means that we can “tag” any future class with this interface and ensure that there is a cancel() function to call since anything tagged with this interface MUST have a cancel function. This means we can maybe stop moving if we are looting or stop looting if we try to fight etc. It is just a way for the StartAction() fuction of being able to take another class with IAction and store it then later call it’s cancel function for sure.
I hope this helps someone a bit.
I understand the concept, I just don’t see the need. If your interface, IDamabable has methods that do nothing but say to the class that implements them, that they must use the properties and methods, why not just define those methods in the class. You must add functionality to the methods anyway.
I have a class Actor which implements the IDamagable interface. I must have a method named Damage that uses the type as the amount of damage dealt, just because I created an interface that says so. I then have to declare the method Damage and give it a parameter for the amount of damage. I can declare the method signature in the class, or even better the base class and I can call it on every other class that inherits from the base class.
If I then have a class Vehicle which can also be damaged, if I implement IDamagable then have to create the logic inside the Damage method, I can just create a Damage method in the Vehicle class that uses logic specific to the class.
What am I missing?
What if you wanted to be able to damage other things besides vehicles…
The effect of that damage might be different for a vehicle (denting the vehicle, perhaps blowing a tire) than a fire hydrant or a building. An interface means that the damage dealer doesn’t need to know anything about the thing that it is damaging, only that it is damaging it. It’s up to the class that implements the IDamage to determine what the damage means.
Now let’s make that more specific to the course, and the IAction interface. A Mover is an Action, and a Fighter is an action. Further in the course, you’ll encounter other actions. Rather than needing to know about Movers and Fighters and Abilities, the IAction interface let’s us cancel the current action without those extra dependencies.