I’m doing similar things like this:
Base class actor holds common data and functions
child classes derived from the base class can be used for any instance of that class that needs special logic
Any data that is not going to change at runtime can be stored and read from a data table asset.
So, an example:
SpaceStationBase actor class has an instance editable string variable called “Type”
You use that string to lookup a data table row.
The data table row holds all information for whatever that type is.
Could be “enemy station large,” “allied station small”, etc.
The data table can hold variables about how long it takes to construct a station, what static mesh to use, etc.
If you have a type of space station that needs unique logic, you can make a child from the space station base class, then you can attach actor components to it for that special behavior.
You could also use the data table to determine what sort of components a station type might use and attach components on the actors BeginPlay event, thus eliminating the need for children classes. This could be a bit messy though so I’d probably separate things if there is going to be more than a few types with unique behavior sets.
If some other class needs to communicate with a station, have the Station base class implement a blueprint interface called something like, “space station BPI”. any children of that class are also going to implement that interface as well.