Im hoping someone can help me with this design decision.
I have a plugin which has ActorComponentA that grants some specific visual features to the actor it is attached to. It has a number of properties and functions.
I have a second plugin which has ActorComponentB which will also grant some specific functionality to actors. However, if the developer has both plugins enabled I want ActorComponentB to basically share both sets of properties and functionality, but if only the this plugin is enabled, otherwise a bare bones implementation of functionality in this component.
I see that advantage of such an approach being:
there is only one component for the developer to add to the actor
one set of properties to manage in one component
decoupling functionality so the components can be used independently if desired
I have considered the following:
Conditional inheritance - if enabled ActorComponentB will inherit from ActorComponentA, else inherit from ActorComponent directly. I cant seem to find any solution where this would work, including the use of ChatGPT.
2 versions of ActorComponentB - 1st version would be the basic implementation, whilst the 2nd would inherit from ActorComponentA, however with this approach I see that the user would have to choose the right component when adding to an actor, and then what would happen if the other plugin is disabled?
Simply having 2 components, where ActorComponentB can check if the module is loaded, if so can call specific functions from ActorComponentA whilst hosting a reference to an instance of it.
So, any ideas on what is the right design approach to handle this scenario? Im presuming that only choice is the last option?
I would very much appreciate any thoughts of what is best practice here. Thanks in advance.
From what you’ve shared, the only approach that makes sense is to have the 2 components potentially be aware of each other and change their behavior accordingly. I wouldn’t check for the plugin I would simply check for the presence of the other component within the component itself.
In practice even that creates some challenges, in that how can I include a class from the other plugin which may or may not be present at runtime.
I was trying to figure out how the engine handles similar situations (at least I think), noting the use of DynamicallyLoadedModuleNames and PrivateIncludePathModuleNames. Then has various checks to see if the module is loaded, if not load it. I havent been able to get my head around that yet to determine if that could work, and failed in my own attempts so far.
The overall goal is not so similar to this other thread, except I want a component in one plugin to have functionality available based on whether the other plugin is available (purchased):
Another line of thought, would be to move that common component to a 3rd Core plugin, plugin A is free to depend on it, plugin B can also depend on it as well.
Thinking about this problem, perhaps this would be the better way to go about it.
Move the code from plugin A for the component to a core 3rd plugin, plugin C making it an abstract class. And not BlueprintSpawnable.
Component B can inherit from that abstract class in plugin B making it BlueprintSpawnable etc. This can be made dependent on plugin C.
Component A can inherit or reference an instance of, from the same abstract class in plugin A also making it BlueprintSpawnable etc. But can have some additional logic to check if plugin B is loaded, if not have the light version, if it is have the combined functionality of both components.