Quick read on Soft Object References
The option to pick between 'Object Reference' or 'Soft Object Reference' is presented when you're adding an object-derived type variable in your blueprint class.
Soft Object References are a path to something on disk. It allows you to refer to a particular object without the engine implicitly loading it in memory.
Gaining the decision to load it (synchronously / asynchronously) when you need it also takes play, and is often key to wise memory management
Why is it important?
Once an asset is loaded, all other assets it has a hard-reference to will also be loaded. This chain tends to grow to the point where “this chain ‘tends’ to grow” becomes quite an understatement.
If you have 500 unique weapons and run a switch statement that determines which weapon is used by returning a non soft reference, also known as hard-reference, you must know that all of the possible weapon picks are loaded into memory, and not just the one being returned.
Usage opportunities for Soft Object References
If you have large quantities of data assets that describe how certain world events unfold in great detail, and run a switch/select to pick one, you must know that all of the possible data assets are implicitly loaded into memory, and not just the one being returned.
Running a switch/select that returns a Soft Object Reference, and loading that whenever you need sails around this.
Your User Widget-derived class represents a shop screen, which neatly displays icons of all available weapons prone for purchase. We know each weapon exists and carries its own cosmetic value, such as market price or strength.
Not only does storing that data outside of the weapon class itself bring opportunity for easy game-design tweaking, you also create a clear distinction between what's stored at runtime, and what could be cooked.
Soft Object References could be used to uniquely identify each actual weapon at any part you wish to do so.
Key Takeaways:
It's understandable that there is some logic involved in picking the right data asset / object. That's the faith most things attain at some point. But ask yourself, is loading the asset relevant during that selection process?
Separating statically definable information from ways run-time information is stored could be beneficial.
Implicit loading of objects in memory provides a seamless blueprint experience. It's a detail which in practice goes unnoticed in many environments, but needs raised attention in more complicated or memory/technical-debt conscious environments.
Have a clear and coherent idea about how classes refer to each other. Staying complimentary to the logically expected outcome - guided by the created perception on what this class encapsulates - means you're doing great.