Should I Create Separate Interfaces for Each Import Type in C++?

0
2
Asked By CuriousDeveloper42 On

Hey everyone, I've got a bit of a beginner question regarding C++ interfaces. I'm working on an import system for my game engine library, where my goal is to convert various file formats into a custom format compatible with my engine. I want to use libraries like Assimp and stb just once instead of reloading them every time I need to access an asset. I'm struggling with how to properly implement classes and interfaces for this.

I was initially thinking of creating a single interface like this:
```cpp
class IAssetImporter {
public:
~IAssetImporter() = default;
virtual void importByFile() = 0;
};

class AssimpImporter : public IAssetImporter {};
class StbImporter : public IAssetImporter {};
```
However, I'm considering whether it makes more sense to split these into distinct interfaces based on asset types:
```cpp
class IMeshImporter {};
class AssimpImporter : public IMeshImporter {};

class ITextureImporter {};
class StbImporter : public ITextureImporter {};
```
I feel like having an interface for each type might just add unnecessary complexity, but I'm open to being wrong here. What do you all think?

5 Answers

Answered By PolymorphMaster On

I generally make interfaces only if I need to create different types of classes that I'll need to manage together. For instance, in my event handling system, all events inherit from a base class, enabling me to support any new event types down the line. There are clever ways to implement polymorphism without strict interfaces too, like using worker classes for various tasks.

Answered By TechWhisperer On

First off, check out this video that might clarify things: [Watch Here](https://www.youtube.com/watch?v=tD5NrevFtbU). And remember to consider why you need to create these interfaces. If it's solely to separate importers, think about what issues that is actually solving. You might find that just a single interface does the job without overcomplicating things.

Answered By AssetExplorer On

Have you thought about just branching based on asset types? You could simplify your imports like this:
```cpp
if (asset_is_a_3d_model) {
// import using assimp
} else {
// import using stb
}
```
This approach might make your code more straightforward without needing separate interfaces.

Answered By CodeNewbie_101 On

You've got a couple of routes you can take. The traditional object-oriented approach would suggest having separate interfaces, like `class IMeshImporter` and `class ITextureImporter`. This way, classes like `AssimpImporter` and `StbImporter` can implement the interfaces relevant to their specific functions. But keep in mind, C++ doesn't have true interfaces – it uses multiple inheritance, which can get tricky.

Also, ask yourself if you actually need runtime polymorphism. Sometimes, it might be simpler to instantiate each importer and select the right one based on the file type directly in a manager class. This bypasses the need for virtual methods altogether!

Answered By GameDevGuru On

For a custom game engine, you probably won’t need diverse importers implementing different interfaces often. Assimp and stb likely cover all the formats you'll need. You might want to focus on creating interfaces for your actual assets instead, like `class D3DTexture: public ITextureAsset` and `class VulkanTexture: public ITextureAsset`, where `StbImporter` processes data to these assets.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.