Static Function/Blueprint Library abuse?

[Awdogsgo2heaven]

Hello! I'm sorry, while I have been programming for a while, but I'm fairly new to 'game programming' as such, I find myself unsure about certain design choices as I'm tempted to apply the logic I've used outside of game programming.
One of the things I've been struggling with is Blueprint Libraries. I use a mix of C++ and Blueprints in my project - I mostly use the Blueprints to handle visual aspects, and core logic C++ side.

One of the things I most frequently do in my projects is separate the data and logic. As such most of my data for players or monsters are basically just objects with properties, and decidedly moved the 'game' logic associated with them to 'services' (which my GameMode calls). To make the bridge between C++ and the services easier for me, I've been putting them all in Blueprint Libraries, as the result, I have more than a few Blueprint Libraries. The issue is, all these Libraries are basically collections of static functions- (I usually pass the data object in as the first parameter- I am not using any static variables, just wanted to put that out there), and my gut tells me this is bad as I usually rarely use static functions and I shouldn't be using static functions all over the place like this. Is my gut wrong? Should I be doing this differently? If so, what should Blueprint Libraries be 'reserved' for?

[Zhi Kang Shao]

The biggest disadvantage to me is that you miss function overriding. If you use class inheritance and a static function should do something special for the subclass then you must either type check inside that one function or have two separate static functions, one for both classes.

Also using your approach all functions are in a global scope. You have to know exactly which function you are looking for because VS auto-complete is less effective I think. UE's context sensitive menu still works well I guess because it matches params which is awesome.

Like yourself I like to separate data from logic, but in other ways. In C++ I store most data in structs and I create blueprint callable getters and setters. I like this because it keeps header files small and the class scope well organized. I like my VS auto complete. The logic I just keep in the actor classes and blueprints.

I do use static function libraries, usually for utility functions that are used across multiple classes. For example: casting game mode base classes to your classes such as Pawn to MyPawn. Also your special math functions, enum to some value conversion, that kind of stuff.

[Awdogsgo2heaven]

The biggest disadvantage to me is that you miss function overriding. If you use class inheritance and a static function should do something special for the subclass then you must either type check inside that one function or have two separate static functions, one for both classes.

Also using your approach all functions are in a global scope. You have to know exactly which function you are looking for because VS auto-complete is less effective I think. UE's context sensitive menu still works well I guess because it matches params which is awesome.

Like yourself I like to separate data from logic, but in other ways. In C++ I store most data in structs and I create blueprint callable getters and setters. I like this because it keeps header files small and the class scope well organized. I like my VS auto complete. The logic I just keep in the actor classes and blueprints.

I do use static function libraries, usually for utility functions that are used across multiple classes. For example: casting game mode base classes to your classes such as Pawn to MyPawn. Also your special math functions, enum to some value conversion, that kind of stuff.

Thanks! I was using Structs, but my main issue was Structs in array, as there was no way in blueprints for me to manipulate the instance itself, I had to pull it out, make changes to it, and re add it to the array. Did you ever find a graceful way of working with this ?

Currently, I keep my data in 'File' class on my game instance so it can be accessed easily in the world (and it makes saving easy since I just call the save at the root). But these are all UObjects.