TL:DR :
Is it bad design for child instances to require setting a variable in order for parent class function to work? If so, how can I better structure my blueprint code to avoid that?
I have a parent widget class that has a function which intakes an instance editable variable.
Each child widget will set this “taget scroll box” to their own scroll box (these are added at runtime so it must be variable).
Then, in the parent widget, since the function is always the same for any children, only the target might change, I have this function there:
But in order for this to all work, it depends on me remembering that I need to set that Target Scroll Box variable in each instance.
The only form of protection I can think of to ensure I’ve done so it to check if the variable is valid before you using it and use a print log to warn if its not. But is there not a better way I could put an actual failsafe into the parent class itself?
Perhaps a better way to design this setup altogether? I am a solo developer so protection against other people isn’t necessarily needed, but I feel that if I can design that way in general it may help reduce total cognitive load if i dont need to worry about one thing depending on another as much.
Hey thanks for this, I am marking as solution because lots of helpful info.
I ended up refactoring the code involved here in a totally different way which solved this part of the problem. I usually try to update threads if I reached a solution but I guess I forgot in this case. I would share code but I dont have my workstation available at the moment.
The gist of what I did was implement the Command Pattern so that I am encapsulating… well, commands, into uobjects.
What this changed was that I didn’t need to define a “target container widget” at all anymore. Each command object just knows which widget it wants to communicate with. So in each command object, for instance there is one called “transferItemGroundToEquipped,” then I just get the inventory HUD, get the EquippedScrollBox, and that is the target. And then for “transferItemEquippedToGround,” then I just grab the GroundScrollBox directly.
Tagging with searchable terms a fantastic idea. That is something I need to get diligent about. Already this little prototype I’ve been working on is getting bigger than I can hold in head so I think I need to start getting in habit of future-helping myself like that.
1 Like
oh, and one other thing that ties into original intent of this thread about reducing my need to remember stuff:
all these command objects and any member functions I make sure to put into categories with a consistent naming scheme. This way I don’t need to remember specific names, but rather just categories. And even if I forget the categories, because I have some prefixes to filter my own content from engine or plugin stuff, then I can just view my own categories only.
So that’s just another way I found to reduce total amount of “stuff” i got to load into my brain anytime I shift gears from one area of the project to another.
1 Like
