Unity Interfaces vs Abstract Classes - Part 1 - Interfaces

at last i understood how to do interfacing thank you so much

Thank you so much

Before I learned interfaces, I just had a different component that was a monobehaviour that I'd add to any object I wanted to be able to take damage and then invoke an action I subscribed to in the main script of the enemy or whatever it was, in the end it worked really similar to this just that I would get that component in the raycast instead of the interface.

I know that having too many monobehaviours is bad for performance but other than that is there any benefit to this? The thing I liked about my previous approach was that I could just enable and disable whenever I wanted that 'take damage" component to test different behaviors which I don't think I can do with this interface approach without having to start adding if elses, am I missing something here? Thanks

So ITakeDamage is considered a component?

Oh, this was so helpful. After a while this video finally made it click for me: interfaces can be used (among other things, probably) when you want to call a certain method from a certain object but you don't know what exact script of the object will have the method.

I'm imagining a fireball that could damage a player by calling a method on its health script, make something explode by calling a method on one of its scripts, and make something else simple catch fire but not be destroyed (by calling a different method on a different script of that burnable object).

With interfaces, I simply choose one script, already on the objects that could react to the fire (or alternatively make a new script that I would attach to each object), and make that script inherit from an interface (like IFireReactive), and make that interface have a method (for example Reaction). Then, each script inheriting the interface defines what it does when the method is called. In my fireball, upon hitting anything, I get the component IFireReactive of whatever it hit and call its reaction method. Then each object does whatever it was coded to do.

That way I can have one script for all things with fire and one script for all things reactive to fire, with no internal conditionals. The fireball or anything else with fire doesn't need to figure out what is hitting to make it react a certain way or call the right method from the right component, and the script that will react to the fire doesn't need to figure out what object it is in to decide what it does.

Basically, designing with interfaces in mind instead of without using interfaces can save you code complexity and trouble later on when you want to expand your systems or start changing things.

Hey, thanks for great guide! What would we do in best practice if we wanted to damage spesific for example "5 damage to car" and "2 damage to barrel"? We are here wont be able to change by it. Maybe we can increase their hp in their class. But what would be the other way?

"
ITakeDamage damagable = hitInfo.collider.GetComponent<ITakeDamage>();

if (damagable != null)
{
damagable.TakeDamage(5); // here we damage all Idamagable interfaces
} "

Great tutorial! Q: do you see this pattern as a good alternative to using events for things like damage? Or are event systems preferable? Or would you use both interfaces and events in the same game?

I've become accustomed to using something more like this. ``` if( hitInfo.collider.TryGetComponent(out ITakeDamage damagable)) {//Do stuff with damagable} ``` This way you don't have things allocating in the Editor when the requested component does not exist.

I literally snorted when you tried to make the health variable public and physically couldn't force yourself to do it.

its all so tiresome

Hey Jason, I've tried this in my own project, but it doesn't seem to work. I mean, I watched it work in your project, but I can't seem to get GetComponent to work on Interfaces in my project. Has anyone confirmed this actually works? (I know my raycast is hitting the object I want, but the GetComponent<>() call always returns null).

If an interface had multiple methods, they would all need to be implemented right?

I like to think of interfaces,as "Declaring" what they do,for example ITakeDamage if you put this interface in any class it says "Hey i take damage man!"

I finaly understand Interfaces. thanks.

i'll die to know how monobehaviour works

Really clear explanation. Thanks for doing these.

nooooooooooo

I have a cold. it's a few hours before the New Year 2020. i'm all alone and learing about Interfaces. Live is good :)

ty

You did, what for some reason I could not find anyone else to explain properly (not even my paid Udemy courses).

How to properly call something on another object, who implements the interface, without having to know about it.

Thank you so much! Subscribed.

Great tutorial thank you!

I can only subscribe once bro! Thanks for your work.

You just saved my life. I ran through the whole internet trying to find a way to "access a script without knowing its name", and Interfaces seem to be the way! I'm making a turn-based strategy game and all I wanted to do is to grab into the GameManager the script of whichever gameobject I click on. Thanks a lot!

Perfect! Thank you!

You teach really, really well. Thanks for everything, man.

Hello there,
Great video. First time it clicked for me. So where can i get more on this programming related topics? Is this video part of a series/playlist? I'd like to dig in some more. Cheers.

But i can have a script called "Damagable" (with a take damage method in it) a normal class and add to all the damageable objects and check if that script exists and do GetComponent<Damageable>().TakeDamage();

Thanks for this video, brilliant, and you work so quickly as well. I wish I knew about Interfaces a year ago, might have saved me some hassle haha. I'm going to implement some now and hopefully improve my game. I really should learn more C#.

Watching your videos is like, the first time I went to United States.. everything was like rich and abundant..(compared to my country)

You are cool.

Like being on a dessert and then I arrive on the oasis.. feels good man.

I mean this; i have watched so much tutorials.. Informations and oh my God.. At last i get it!!!

Thank you!
from my hearth of hearths !! Appreciated

A light shines forth on the horizon. As i understand this problematic concept.

Sir.. I tip my fedora; and take damage with a smile.

@Unity3dCollege
thank you sir for this incredible video sometimes you make really incredible videos like this, i just want to say after all this words you took your time to read even though i don't know what i am trying to say is that i have no other words to say how grateful and thankful i am for coming across to this awesome epic ultra awesome tutorial about interfaces , i just want to say a big big big thank you !!!

It is super amazing.

You're the best !
Thank you !

U ARE UNITY GOD MA-BOY !!

this dood looks like a bum but he is SO mfing smart

Your videos are completely changing the way I do things for the better. When I can afford it, I want your master classes!!

As a massive fan of abstraction in my code you have taken possibly 2 or 3 classes of look-ups and simplified everything and saved me days of work. Thank you so much!
I'm a dangerous but knowledgeable coder, so in a month after changing my code around and adding more features if you can show me how I can create a pointer to a char and cast that to a bool in C# OR even tell us how we can build and call some C++ functions (some from other C++ libraries) I can create a feature to make some fun as hell saved games in some fun and exciting formats.

I choose to just create a monobehav. script that handles damage and drag it to any gameobject I want to have health. Thereby eliminating the need to add interfaces to every script .

Thanks for the explanation--working on sorting out these definitions and your video was a big help.

Great tutorial- thank you!

Fantastic Tutorial this!!

As someone who has watched shit loads of tutorial videos about everything, this is a fresh new channel taking on some less popular topics (not necessarily this topic but others). Videos are great, my request for a video is adding high quality lighting to a 2D game in Unity.

you just changed the game for me :D

The one thing I consistently have the most trouble with in Unity is the overall architecture of my code. Everything ALWAYS ends up becoming a tightly coupled monolithic structure that is impossible to extend beyond a certain point.

Here is an example of the kind of problem I end up encountering:

- UI. Should my UI 'observe' the game logic it's representing and update itself as it's own thing (and have the game logic/objects be oblivious to the UI), or should the UI be directly updated from the game objects that it is supposed to represent. I imagine it would be the former, but then I run into issues, like; how do I ensure the UI is aware of game objects that get instantiated or altered at runtime AND require UI representation without those game objects actively updating the UI or being at least somewhat aware of the UI in order to notify it that it exists.

Inevitably what ends up happening is my UI gets controlled by the game objects in order to solve the 'awareness' issue and to satisfy all the different types of UI behavior I want, and then I end up with bugs that relate to the UI being controlled from multiple places (eg. if I have other 'global' scripts controlling UI visibility based on the game state, as well as UI being controlled by the individual game objects it's representing).

Do you have any general tips or pointers (tutorials etc) for info on how to solve these more broader 'architectural' type problems?