As a computer science major I was constantly taught to “program to interfaces”. It seemed like the answer to all of the questions the professor asked in my design classes was always, at least partially, “program to interfaces”.
So after spending quite a bit of time in the Unreal Engine I decided I needed to start actually designing my code instead of just going for it, and the first hiccup that I ran into was interfaces in UE4. They seem to be incredibly confusing and almost pointless (based on what I’ve read about them in the AnswerHub and the UE4 forums), and I realized this first hand when I tried to return a pointer to a UE4 interface and got hit with all sorts of compiler errors. Looking online people said to use TScriptInterface instead but that brought all sorts of new complications and it felt like all of the benefits of using interfaces was completely lost in the obfuscated code required to get them to work.
I’m wondering if any more seasoned UE4 developers have an opinion on this? Or does anyone from the GameDev.TV team know if there’s going to be an addition to the UE4 course explaining this concept? It’s possible that I’m making it more complicated than it should be, and if so then some direction would be hugely appreciated! Thanks!
I suppose you were working a lot in Java, right? I learned the same stuff in regards of working with C#. And while I have to say that I really like the approach of working with interfaces in these languages, I feel like it is not very common in UE4 and might not be that common in C++ programming in general. Especially since in C++ there are not the Java/C# interfaces. Instead the language only provides abstract classes. In Unity I used it all the time. Now in regards of UE4, I haven’t really used it that much. I sometimes created an interface class, to simply group different classes and let them share a certain attribute or method and have them be identified by other classes without the need to know which specific class I am dealing with, but haven’t gone crazy with them yet. Thing with C++ in general is that many design approaches can’t be applied directly and need some C++ specific tweaking. UE4 is bringing even more stuff to consider to the table. But overall I feel like working in UE4 C++ becomes quite straight forward, once you got a hang of it.
Thanks for your respone @Pe_Emm! I think I’ve probably spent more time in C++ but it was longer ago now so I’m getting pretty rusty I guess haha have you ever tried using abstract classes with multiple inheritance in UE4 as interfaces? I was planning on trying that out today. I’m starting to think that UInterfaces are more for exposing interface-like things to blueprint than for replicating Java-style interface behavior.
I haven’t done multi inheritance with abstract classes yet. Since, as you said, I used it more to treat all blueprints that abstract from a a base class that implements an interface in a certain way. So, if you can do the Java style interface code approach… not sure. But I believe, since UE4 does offer interface classes, Epic at least tries to offer you the possibility to write code that way. From my experience I never found it to be the smartest approach to program big interfaces, since most of the time, I was fine with a base class and abstract blueprints from it or split my logic into small components and connect them in a blueprint. But well, if you are working in a gigantic project and everything has to be as generic as possible and tight coupled depencies are to be avoided, I believe they could become handy - given they work correctly.
Actually thanks for this one. I’ve always wondered why so many programmers at my work does the silly.
methodCall -> shellMethod -> actualMethod thing.
Java and C# has to hide allot of the ‘inner workings’ to avoid interpreter operations from being interrupted.
With C++ you have none of that. The only interpreter here is the compiler. C++'s paradigm is to have raw access with the ability to mask with abstraction.
It is one of the reasons Linus Travolds hates C++ for this masking behavior as it puts an unnecessary lair of obscurity between the memory and processing components.
This isn’t so much UE4 than it simply is c++ funny. You can have a look at virtual methods and the like. But overall C++ is still pretty C based where explicit is better than implicit, so I suggest avoiding large Java style layers of abstraction.
but shouldn’t that still leave the option of creating pure virtual abstract classes which in return can be used instead of high level interfaces. I mean pure virtual functions are destined to be declared by the class that inherits the abstract class, it ensures that all classes that inherit said one are guaranteed to have an implementation of the functions the abstract class demands and it can be given to any parameter list to insert any class that implments the abstract class. Or am I missing something? I mean it feels like it is more of a technical difference, since a class can inherit multiple abstract classes and it is inheritance opposed to implementation.
But if I think of some examples where I used interfaces in unity and C#, it should be possible to be done in a similar fashion in UE4 and C++. For example having an interface for items. I could give it a pure virtual function void UseItem. If I then had a quickloadslot that is only checking for an object that implements Item, the method UseItem could do whatever it wants as long as it is there. I see no reason to not do that in C++, especially compared to having a base class and commit to an inheritance hierarchy. Or is there any reason to not do it that way in C++??
Sorry, I re-read and yeah I jumbled words… (no coffee mode) Yes, it is completely possible. And while yes you can use interfaces in C++ I was just pointing out one must be critical of their use. You’re adding a huge overhead to the structure of the execution map sent to the CPU. And if there’s no valid reason for it, it’s wasted CPU time.
The amout of overhaead is something I didn’t consider, fair point! So for that purpose would you solve a problem of the like I described above rather with regular inheritance? Since in that case you must have a solution that any object can be passed. I mean you could also write a class ItemBase and let every specific Item inherit from ItemBase (sorry, feels so weird to type that since I was always taught, never use inheritance unless you have no other options left)
I suppose the overhead comes due to the number of method calls. If thats the case then it would not be solved by regular inheritance since it would in the described case only shift the problem.
Well to be honest, this has had me hitting the books again. You can use a pure inheritance structure to achieve the same goal. But in some cases making a polymorphic Interface class is best.
I was just trying to post the argument that getting that implemented has a cost. There is even a video on the cost of virtual methods which is how Interface classes are structured in C++.
The overhead here is, the moment you implement any of such classes most of the method declarations get nested in a call tree. And I’ve seen… some things.
Some developers make Interface classes based of interface classes based off interface classes.
Or at least that’s the horror show I once had to deal with. Being someone who mostly uses inheritance for structured coding. I find these grotesque to maintain/modify.
But to correct myself, it seems Interfaces are indeed part of C++'s paradigm and I apologize for the confusion
Hehe, yeah I did the same. And this is also the article that I found.
My conclusion is that it doesn’t seem to be a bad choice for certain things. I mean I think you can pretty much get away with only using it in cases where you inject objects into any function and need to make sure it has a certain function, while guaranteeing expand-ability of your code by doing so and easier maintainability.
But it looks like it is a bad idea to create an outlined interface for every class you want to create. But yeah, I know what you mean, some people overdo things
