How common is it to have a "MyNode" class and then a "MyNodeData" custom resource?

Godot Version

Any

Question

I keep falling into this pattern, and I’m wondering if it’s an antipattern.

I have some class MyNode which represents some scene – maybe the player character, maybe enemies, maybe some other kind of object, that has a fair amount of data. I want to store this data reasonably and maybe have different objects of the same type load different data types (say, Guard vs EliteGuard), which have different statistics but otherwise operate the same way. I don’t want this data only stored in the scene which these objects are placed in, since I want it to persist independently, be able to be swapped out, etc. So I end up making a MyNodeData (Which is a CustomResource) class that handles that customizable data. This way that data can be independently edited, saved, and loaded. If I want to try a different set of parameters, I can make a copy of the resource and modify it.

MyNode often has plenty of other variables, for its internal workings, which may or may not be exposed to other objects (i.e., public properties in c#) but that doesn’t go into MyNodeData — just kind of parameters or stats that I might want to tweak.

I’ve found it can be an issue when refactoring, but I think this kind of thing is always an issue when refactoring? Often the data has to be reset when classes change. (This can be a little painful, given I’m new to Godot and trying different ways of doing things.) Separating one of the other might actually help sometimes though?

I’m just wondering if this is common or not, and/or if it is seen as good or bad practice. If it’s a bad practice is there a general “here’s what you should be doing” like of like “Don’t using get_parent().get_parent().get_…, instead use signal up, call down”?

if i understand you correctly… you are using composition and that is a design principle: “privilege composition over inheritance”.
some patterns like the strategy pattern use this approach.
basically, you are breaking up a large class into smaller classes, separating behaviors or states that can change.
if this is not your case, you may need to add a code example

1 Like