Could you do a comparison about the pros and cons of using an interface vs an abstract class? Looks like interfaces seem better since you can add more of them to one class
I actually did one a bit ago here - czcams.com/video/kYJRIWjoeFA/video.html It's 2 parts, one about the interface side, the other for abstract classes, and when I use each :)
If we split up an interface like in this example IEntity into separate interfaces (for example IHealth and IAnimatable - for handling animations), and we want a method to take one object and do operations from both interfaces, what is the best way to handle that? Does one then re-implement a IEntity interface which inherits from IHealth and IAnimatable, or does the GameObject now have to be passed twice (eg. someMethod(IHealth health, IAnimatable anime))
This was a great tutorial! As someone very new to unity and C# I'm curious about the example that was being developed however, specifically in regards to where the AttackProcessor method would be stored. In other videos on interfaces I see a common setup as developing an ICanTakeDamage interface that then includes a TakeDamage method. All the classes that inherit the ICanTakeDamage interface then have that TakeDamage method within them to handle how it applies in each case. This doesn't seem to be the intention here with AttackProcessor however. Would I be right to think something like AttackProcessor would then live on an empty game object, which can then be referred to? I'm curious on what an 'elegant' method is to include AttackProcessor in a generic way that any item taking damage could make use of it, without copying the code out in multiple scripts/classes. Appreciate this wasn't the intent of the video but I'm curious now!
Hey there :) So I'm playing around with coding a simple SkillSystem. Following the SOLID principles, I have run into a small issue by using interfaces. This is the relevant part of my code: public class SkillData : ScriptableObject { private bool isActivated; private List prerequisites; public bool IsActivated { get { return isActivated; } private set { isActivated = value; } } public interface IPrerequisite { bool PrerequisiteMet { get; } } public class NeedsSkillData : IPrerequisite { SkillData neededSkill; public bool PrerequisiteMet { get { return neededSkill.IsActivated ? true : false; } } } So far, I don't think there's anything wrong with the code itself, but Unity doesn't seem to support interfaces in the editor/inspector. Is there a way to make the List prerequisites appear in the Inspector to make it able to actually add the prerequisites? I know I could work around this by simply changing my interface into an abstract class, but I'd like to keep it as an interface if possible.
You can apply any number of interfaces on a class by separating them with commas. For instance: public class Door : IHaveHealth { //code goes here } public class NPC : IHaveHealth, IHaveStats, IBlahBlah //and so on { //code goes here }
Sorry but let me ask, in ur interface u have a property DamageShiedlController, but the "Dependence Inversion Principle" says that u have to depend the Abstraction, not the Implementation. So i think that u need to create IdamageShieldController isn't?
I think you missed something rather important when designing very granular interfaces: combining interfaces. Say if you have class that runs combat between two entities. These entities would need to both have IStats and IHealth. To represent this, make a third interface called ICombat that inherits from both IStats and IHealth, it's a combined interface that anything that implements enough functionality to support combat. It also means that you can access both stats and health from anything involved in combat, something not feasible using only the more granular interfaces. So to continue with your example of attacking the door, the door would technically need to implement the IStats interface just to work with the generic combat engine, but most of its stats would be 0. The combat engine doesn't even know it's a door, it just knows it's something that satisfies the requirements for combat. Otherwise attacking a door would be different than attacking an NPC, since the NPC has stats that would affect combat and a door would not. You would have to fudge in a few bogus stats, a door has 0 intelligence for example, but a door is quite tough, it should have a high constitution and would even respond to constitution-based saving throws and such.
Sorry, I missed that. However, that's still not exactly what I'm talking about. The way he did it, you can't have anything that implements health without implementing stats. That might be what is intended for that use case, but having individual IHealth and IStats interfaces and a third IFightable interface that inherits from both would be both more clear and more flexible. The objective when designing small, granular interfaces is to compose them into larger interfaces, not to arrange them in a hierarchy as you would with classes. That's taking a step backwards, and re-implementing the same problem that classes introduced in the first place, just with different keywords.
I see your points but I think it kinda pushes back against the core of the principle. If I need to add a IHaveStats or another interface that has it to the door, I'm directly violating the principle, requiring the door to implement things it doesn't need. If I didn't mess up the example, attacking a door should be completely possible, without it requiring any stats on the target at all. Instead, the attacker had a larger set of requirements, requiring the IHaveStats to calculate out the amount of damage dealt. Hope that makes some sense :) (note I do also have some bigger interfaces that combine multiple of the small ones just for simplicity, but I don't code against them and instead code everything against the lowest possible interface I can)
@@Unity3dCollege The code will work perfectly for now, but what if we decide to take the NPC's DEF stat into consideration when calculating the damage? Then we will need to make the target of type IHaveStats after all and assign a DEF of zero to the door right? Is there a better way to do this?
Could you do a comparison about the pros and cons of using an interface vs an abstract class? Looks like interfaces seem better since you can add more of them to one class
I actually did one a bit ago here - czcams.com/video/kYJRIWjoeFA/video.html
It's 2 parts, one about the interface side, the other for abstract classes, and when I use each :)
I was having issues trying to understand why is using interfaces good. But this example made total sense. Thanks.
Glad it's making sense. in some projects it just overcomplicates things, but when they get a bit bigger it can really make a difference :)
I've never seen before inheriting interface from another! :)
Thank you for existing! I rarely find this level of competence on youtube :) Sub & Liked
Thank you! :)
Wonderful video, please do more videos regarding the principles of programming.
I definitely will, thx
Mind blown.
Thanks for the wisdom man!
you're welcome :)
"doors shouldn't have any intelligence, at least not any that I've seen" - You haven't seen Hitchhikers Guide to the Galaxy? ;)
sigh.....
哈哈哈哈哈哈，你个杠精！
Finally someone explains SOLID principles like a real COLLEGE does ;) Love your vids!
Thank you, this SOLID series is wonderful so far.
Thanks! :)
Hello Jason, awesome video! I'm currently struggling with interfaces, thanks for the rescue
Glad it was helpful
simple and ingeniously
Superbly explained! Thx🤘
Love this. Interfaces are fun, and great practice.
I love these tutorials. Thank you so much, man.
A way better example on SOLID then the one passed by EDGE in Unity Talk
I really love your way of coding! You are awesome!
Great video, very useful info and examples- thank you.
U R welcome
Awesome as always !!! Thanks Jason :)
thank you!
If we split up an interface like in this example IEntity into separate interfaces (for example IHealth and IAnimatable - for handling animations), and we want a method to take one object and do operations from both interfaces, what is the best way to handle that? Does one then re-implement a IEntity interface which inherits from IHealth and IAnimatable, or does the GameObject now have to be passed twice (eg. someMethod(IHealth health, IAnimatable anime))
This was a great tutorial! As someone very new to unity and C# I'm curious about the example that was being developed however, specifically in regards to where the AttackProcessor method would be stored. In other videos on interfaces I see a common setup as developing an ICanTakeDamage interface that then includes a TakeDamage method. All the classes that inherit the ICanTakeDamage interface then have that TakeDamage method within them to handle how it applies in each case. This doesn't seem to be the intention here with AttackProcessor however. Would I be right to think something like AttackProcessor would then live on an empty game object, which can then be referred to? I'm curious on what an 'elegant' method is to include AttackProcessor in a generic way that any item taking damage could make use of it, without copying the code out in multiple scripts/classes. Appreciate this wasn't the intent of the video but I'm curious now!
I found an error. STA should be DEX.
Little did he know that the Door was a Mime and also the Main Character!
Hey there :)
So I'm playing around with coding a simple SkillSystem. Following the SOLID principles, I have run into a small issue by using interfaces.
This is the relevant part of my code:
public class SkillData : ScriptableObject {
private bool isActivated;
private List prerequisites;
public bool IsActivated {
get { return isActivated; }
private set { isActivated = value; }
}
public interface IPrerequisite {
bool PrerequisiteMet { get; }
}
public class NeedsSkillData : IPrerequisite {
SkillData neededSkill;
public bool PrerequisiteMet {
get {
return neededSkill.IsActivated ? true : false;
}
}
}
So far, I don't think there's anything wrong with the code itself, but Unity doesn't seem to support interfaces in the editor/inspector. Is there a way to make the List prerequisites appear in the Inspector to make it able to actually add the prerequisites?
I know I could work around this by simply changing my interface into an abstract class, but I'd like to keep it as an interface if possible.
Great video :)
How would you apply the interfaces on objects like a door, and or NPC?
You can apply any number of interfaces on a class by separating them with commas. For instance:
public class Door : IHaveHealth
{
//code goes here
}
public class NPC : IHaveHealth, IHaveStats, IBlahBlah //and so on
{
//code goes here
}
doors in smart homes need an int stat
Give it a few more decades, I'm sure doors will gain intelligence at some point.
Sorry but let me ask, in ur interface u have a property DamageShiedlController, but the "Dependence Inversion Principle" says that u have to depend the Abstraction, not the Implementation. So i think that u need to create IdamageShieldController isn't?
What about automatic doors?
I think you missed something rather important when designing very granular interfaces: combining interfaces. Say if you have class that runs combat between two entities. These entities would need to both have IStats and IHealth. To represent this, make a third interface called ICombat that inherits from both IStats and IHealth, it's a combined interface that anything that implements enough functionality to support combat. It also means that you can access both stats and health from anything involved in combat, something not feasible using only the more granular interfaces.
So to continue with your example of attacking the door, the door would technically need to implement the IStats interface just to work with the generic combat engine, but most of its stats would be 0. The combat engine doesn't even know it's a door, it just knows it's something that satisfies the requirements for combat. Otherwise attacking a door would be different than attacking an NPC, since the NPC has stats that would affect combat and a door would not. You would have to fudge in a few bogus stats, a door has 0 intelligence for example, but a door is quite tough, it should have a high constitution and would even respond to constitution-based saving throws and such.
He did combine interfaces. His IHaveStats Interface inherits from IHaveHealth because anything that would have Stats would have Health.
8:20 look here
Sorry, I missed that. However, that's still not exactly what I'm talking about. The way he did it, you can't have anything that implements health without implementing stats. That might be what is intended for that use case, but having individual IHealth and IStats interfaces and a third IFightable interface that inherits from both would be both more clear and more flexible. The objective when designing small, granular interfaces is to compose them into larger interfaces, not to arrange them in a hierarchy as you would with classes. That's taking a step backwards, and re-implementing the same problem that classes introduced in the first place, just with different keywords.
I see your points but I think it kinda pushes back against the core of the principle. If I need to add a IHaveStats or another interface that has it to the door, I'm directly violating the principle, requiring the door to implement things it doesn't need. If I didn't mess up the example, attacking a door should be completely possible, without it requiring any stats on the target at all. Instead, the attacker had a larger set of requirements, requiring the IHaveStats to calculate out the amount of damage dealt. Hope that makes some sense :) (note I do also have some bigger interfaces that combine multiple of the small ones just for simplicity, but I don't code against them and instead code everything against the lowest possible interface I can)
@@Unity3dCollege The code will work perfectly for now, but what if we decide to take the NPC's DEF stat into consideration when calculating the damage? Then we will need to make the target of type IHaveStats after all and assign a DEF of zero to the door right?
Is there a better way to do this?
I wouldn't be suprised if Earthbound had intelligent doors.
Remove the f@#ing 1 dislike